All the adapters included in the calcite's repository are only supporting queries. I found there is a class called ModifiableTable, looks like it is for C/U/D operations. Is there any sample that implemented the ModifiableTable? I dug a long time and can not find one.
It should be possible, but there are are no adapters within the Calcite code base that does this. I am also not aware of any third party adapters which have done this. Although I say it should be possible, it's certainly possible that you will run into some challenges given that it's not a common use case.
It is possible according to the docs - https://calcite.apache.org/docs/adapter.html#server
Calcite’s core module (calcite-core) supports SQL queries (SELECT) and DML operations (INSERT, UPDATE, DELETE, MERGE)
You can see some examples in the tests
https://github.com/apache/calcite/blob/296b84cad4406be03f2db35ce6077ad8fed4fef6/server/src/test/java/org/apache/calcite/test/ServerTest.java#L125
https://github.com/apache/calcite/blob/4bc916619fd286b2c0cc4d5c653c96a68801d74e/core/src/test/java/org/apache/calcite/test/MultiJdbcSchemaJoinTest.java#L70
https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/SqlInsert.java
I suggest checking out the code and looking at the adapter these tests are using.
I will be doing this myself in a few weeks so if you haven't figured it out by then I'll try to remember to post a more concrete example once I've worked it out :)
Related
I am at the first time creating a huge program in C++ for my company and I want to create a good pattern to connect into my MySql db. I have these problems:
-I can't decide which pattern should be used, DAO,
Repository, UnitOfWork, Factory..
-I can't find a good examples of data access pattern in C++, I know it should be independently of language but I couldn't find even a robust
DAO pattern example with a good exception handling etc... Commonly are
only two classes (obj1->obj2) on very small environment.
If someone knows good sources or any tips I will be very glad =D
Thanks in advance.
My advice is search for c++ ORM(Object Relational Mapping) there are plenty ORM or DAL solutions on java like Hibernate, Datanucleus, SQLite ..
We are using Datanucleus and we are happy with it but i dont think datanucleus have a support for c++. Imho creating DAL form scratch is unnecessary.
I had the same problem years ago. The list of ORM for C++ in Wikipedia is very short and the most promising product is under GPL or you have to buy it.
We decide to develop our own ORM. There are several enterprise design patterns for it. We choose the way obd uses: Your tables was described from simple classes. The persistence and access of objects are handled from an database-manager. The most costliest todo is to write your own query-interface (if you don't wand to type clear sql in your code).
I am trying figure out which one (Pedestal, Hoplon, Bidi) should i use? I didn't find any good article in the Internet which help me with this choice.
From https://github.com/juxt/bidi i can read Pedestal is isomorphic, but Bidi is also cljs. What is it mean? What is the difference?
I found compojure is too simply. I can't even generate URLs in HTML templates. I started looking something else. I found also route-one (library to generate URLs working with compojure), but i guess soon i will discover i need something more then compojure have again.
My intuition say me to choose between: Pedestal, Hoplon and Bidi.
What i need:
I want have independent business model architecture like
http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html
http://blog.find-method.de/index.php?/archives/209-Dependency-inversion-in-Clojure.html
I don't want depend this part of code with any framework. Less dependency is better.
On next stage i want inject this model business into something like bridge, which will be the connector with user interface. It can be time for framework or additional libraries.
And at least i want create frontend user interface as website. It will be dynamic content with ClojureScript or mayby static. I don't know. I have to thing about both.
What i found out in Clojure i really like conception of building my own set of libraries based on my preferences. But i don't want write my own code to use things like generate URLs for routes. So mayby i should also consider route-one?
Please write something clever what help me choose one or complicate my live with some other option to choose :)
https://github.com/juxt/bidi
https://github.com/pedestal/pedestal
https://github.com/tailrecursion/hoplon
https://github.com/clojurewerkz/route-one
This is an ancient question, and I don't pretend to have an answer (much less "the" answer). But I'm googling for some of the same basic pieces tonight, and my search results came back with this response.
So I figured I'd jot down notes about my [very] limited understanding here.
Bidi seems awesome. From what I've seen, juxt produces very high quality software. For places where I need REST-style interface routing (which includes sending related routes back), this is my current GOTO choice.
Pedestal - also awesome. But it seems to be a very different use case. Routing
is a very small subset here (and they've tried multiple approaches to come up with a really good set of options). This seems to be more of a fairly low-level full-featured server-side library for integrating the code you care about with the underlying server pieces that you don't.
To be honest, I'm not sure Pedestal's routing libraries really support the reverse endpoints you have to have for REST. I think they almost definitely do, but I'm not positive. My use cases have all been about their interceptor chaining abstraction, which is mind-blowingly awesome.
Hoplon - I haven't looked at this in 2-3 years. At the time, it seemed like a big, bold, high-level kitchen-sink framework that's somewhere in the same ballpark as Ruby On Rails (although I think there are also front-end components). I've been writing API end-points, and this didn't seem like a good fit at the time. It deserves more attention than I gave it.
route-one - I hadn't heard about it before this question. I've gotten good impressions from everything that I have used from clojurewerkz, but that usage has been very light.
Are there any capabilities that one inherently lacks that the other doesn't?
SphinxQL (according to benchmarks on the Sphinx blog) returns queries faster than SphinxAPI for interpreted languages and the premise of such a comparison would likely be that the functionalities present in both are the same.
Why the API then?
Any clarity on this issue is much appreciated.
(This is about the C++ based open source search engine)
I just found a satisfactory answer:
SphinxQL is simply a language for querying Sphinx.
SphinxAPI is a framework that allows you to compute results based on the queries.
The queries could still be via SphinxQL or they could be via the API's syntax...it doesn't matter...SphinxQL and the SphinxAPI are different objects that accomplish different things (as highlighted above)
SphinxAPI is a legacy. That is why I'd rather go with a flow with a API than switch to SphinxQL in production. But for new projects SphinxQL is the only choice as it is evolve quicker and gets all features first. The next big thing that using SphinxQL you don't tie to developer of API for not officially supported languages or platform instead you could use any MySQL client \ library.
I'm trying to find open source applications using PostgreSQL that are written in C/C++ so I can study them. A few open source projects using PostgreSQL are Evergreen ILS, SpamAssassin, and pgpool. However, Evergreen and SpamAssassin are written in Perl, and pgpool (written in C) is a replication tool, not a typical application. Moreover, I looked at the SQL code in Evergreen, and it is quite voluminous and complicated.
Hence, I'm looking for one or more applications using PostgreSQL, preferably those that are somewhat trivial (but not too trivial).
seen libpqxx? try asking on its mailing list (but scour their wiki first)
http://pqxx.org/development/libpqxx
pgAdmin is written using c++ using wxwidgets.
how about pgAdmin 3 ?
Also, you may find Qt4 a very easy way interact with databases programming in C++.
http://doc.trolltech.com/4.6-snapshot/sql-programming.html
Have you searched through the projects at http://pgfoundry.org ?
Two examples that are open-source:
Kexi (see kexi-project.org)
FOST4 (
http://support.felspar.com/Fost%204 )
It's pretty big, but the KDE Project's Amarok is written in C++ and can use a PgSQL backend (among several others). While it's pretty large, you may be able to find some interesting things in the database code. Since it uses a pre-defined schema (as opposed to the extremely general types of access that something like pgAdmin uses) it may have some good things to teach you. It will definitely be easier to pick apart than Evergreen, which actually has an entire middleware layer that actually does the data access through exposed services (The OpenSRF Project).
In a C++ application that can use just about any relational database, what would be the best way of generating queries that can be easily extended to allow for a database engine's eccentricities?
In other words, the code may need to retrieve data in a way that is not consistent among the various database engines. What's the best way to design the code on the client side to generate queries in a way that will make supporting a new database engine a relatively painless affair.
For example, if I have (MFC)code that looks like this:
CString query = "SELECT id FROM table"
results = dbConnection->Query(query);
and we decide to support some database that uses, um, "AVEC" instead of "FROM". Now whenever the user uses that database engine, this query will fail.
Options so far:
Worst option: have the code making the query check the database type.
Better option: Create query request method on the db connection object that takes a unique query "code" and returns the appropriate query based on the database engine in use.
Betterer option: Create a query builder class that allows the caller to construct queries without using any SQL directly. Once the query is completed, caller can invoke a "Generate" method which returns a query string approrpriate for the active database engine
Best option: ??
Note: The database engine itself is abstracted away through some thin layers of our own creation. It's the queries themselves are the only remaining problem.
Solution:
I've decided to go with the "better" option (query "selector") for two reasons.
Debugging: As mentioned below, debugging is going to be slightly easier with the selector approach since the queries are pre-built and listed out in a readable form in code.
Flexibility: It occurred to me that there are some databases which might have vastly better and completely different ways of solving a particular query. For example, with Access I perform a complicated query on multiple tables each time because I have to, but on Sql Server I'd like to setup a view. Selecting from the view and from several tables are completely different queries (i think) and this query selector would handle it easily.
You need your own query-writing object, which can be inherited from by database-specific implementations.
So you would do something like:
DbAgnosticQueryObject query = new PostgresSQLQuery();
query.setFrom('foo');
query.setSelect('id');
// and so on
CString queryString = query.toString();
It can get pretty complicated in there once you go past simple selects from a single table. There are already ORM packages out there that deal with a lot of these nuances; it may be worth at looking at them instead of writing your own.
Best option: Pick a database, and code to it.
How often are you going to up and swap out the database on the back end of a production system? And even if you did, you'd have a lot more to worry about than just minor syntax issues. (Major stuff like join syntax, even datatypes can differ widely between databases.)
Now, if you are designing a commercial application where you want the customer to be able to use one of several back-end options when they implement it, then you may have to specify "we support Oracle, MS SQl, or MYSQL" and code to those specific options.
All of your options can be reduced to
Worst option: have the code making the query check the database type.
It's just a matter of where you're putting the logic to check the database type.
The option that I've seen work best in practice is
Better option: Create query request method on the db connection object that takes a unique query "code" and returns the appropriate query based on the database engine in use.
In my experience it is much easier to test queries independently from the rest of your code. It gets a lot harder if you have objects that are piecing together queries from bits of syntax, because then you have to test the query-creation code and the query itself.
If you pull all of your SQL out into separate files that are written and maintained by hand, you can have someone who is an expert in SQL write them (you can still automate the testing of these queries). If you try to write query-generating functions you'll essentially have a C++ expert writing SQL.
Choose an ORM, and start mapping.
If you are to support more than one DB, your problem is only going to get worse.
And just think of DB that are comming - cloud dbs with no (or close to no) SQL, and Object databases.
Take your queries outside the code - put them in the DB or in a resource file and allow overrides for different database engines.
If you use SPs it's potentially even easier, since the SPs abstract away your database differences.
I would think that what you would want to do, if you needed the ability to support multiple databases, would be to create a data provider interface (or abstract class) and associated concrete implementations. The data provider would need to support your standard query operators and other common, supported functionality required support your query operations (have a look at IEnumerable extension methods in .NET 3.5). Each concrete provider would then translate these into specific queries based on the target database engine.
Essentially, what you do is create a database abstraction layer and have your code interact with it. If you can find one of these for C++, it would probably be worth buying instead of writing. You may also want to look for Inversion of Control (IoC) containers for C++ that would basically do this and more. I know of several for Java and C#, but I'm not familiar with any for C++.