I'd love to be able to seamlessly send and receive Protobufs from my C++ applications to a Database and back. I'd be happy to create some kind of adapter on the client side, or to leverage an existing plugin on the Database side.
Has anyone encountered something that does this?
EDIT: As for the flavor of database, I'm open to all options, but had assumed a traditional relational database (PostgreSQL, MySQL, etc). If this is the project that forces me to try one of the fancy modern DB technologies, then so be it
Related
I was curious if Flight SQL will be an alternative to libraries like turbodbc? I am using turbodbc to query many different database flavors to return data in a pyarrow table, but I have had to add the OBDC drivers to my Docker image.
Is this something that can be used to query databases as a read-only user, or would something need to be done server side to support Flight SQL?
Flight SQL requires something database-side, yes. It's lower level than something like ODBC or JDBC, which (for instance) don't specify anything about the wire protocol; instead, it's a set of libraries intended to be used with a particular RPC protocol.
That said, it is intended to support use cases like yours. It's just that implementations are forthcoming (and things like Python bindings). Reaching out on the Arrow mailing list may get some more attention: dev#arrow.apache.org
UPDATE 2022/07: the more direct alternative to something like turbodbc, ODBC, JDBC, etc. in the Arrow ecosystem is under development as "ADBC": https://github.com/apache/arrow-adbc This is an API abstraction layer, so it doesn't require a remote server or local proxy, so long as you can somehow bend the database (client) to the proposed API.
I want to write an application which should be able to connect to multiple databases (this will be configured by parameters at startup). The application will have different queries for each database engine, this is not a problem.
The problem is that I want to be able to connect to different database engines. Java has JDBC, Perl has DBI. What does C++ have?
What's more I don't want to use database drivers with too strict licences (commercial ones). GPL could be - but I'd like to avoid that.
Virtually every database engine in existence provides an ODBC interface. I think JDBC is actually a clone of ODBC.
What you want, then, is a C++ wrapper for the ODBC API, that implements RAII to make sure that database resources are released in case of exception, etc. For example: http://simpledb.sourceforge.net/
There is the older OLE connections. Using OLE, you could connect to a Flat File, Oracle, SQL, or MySql database provided you have the correct drivers installed.
ODBC is most compatible and most low-level. OLE DB is higher level and easier to work with, so if you find OLE DB provider for all your possible DB systems, it is the way to go. Otherwise ODBC is your option as virtually all DB systems support it.
EDIT: View this link: http://blogs.msdn.com/b/sqlnativeclient/archive/2011/08/29/microsoft-is-aligning-with-odbc-for-native-relational-data-access.aspx This makes ODBC the only proper choice. :)
The C++ object-relational mapping system ODB from the company Codesynthesis can be used by GPL version 2 software.
http://codesynthesis.com/products/odb/
Here is a blog entry where they describe why they chose to use native C APIs instead of ODBC to connect to the databases.
http://codesynthesis.com/~boris/blog/2011/12/09/oci-mingw/
Speed was one of the reasons.
I want to try hooking up my pet project to a NOSQL type DB as eventually it will need to be able to process a large data volume with a very simple data structure...pretty much ideal for NOSQL.
However I am using C++ and have 0 interest in writing a wrapper around a C client. I googled some to try and find examples for using Cassandra with a C++ client and didn't find much.
So my requirements are: Free, Runs on Windows, Good C++ client with examples available that don't assume I am already a NOSQL / Thrift guru.
Any thoughts?
Redis has clients for most major programming languages, including C++. Everything I've been hearing is that Redis is the new hotness in NoSQL.
The thing about Redis (and memcached) is that they ultimately provide telnet-like interfaces. If you can open a socket to localhost and send commands, you can use the NoSQL database. That's more or less what Rediska (Redis PHP Client) does under the hood.
You should be able to whip up a dumb get-set interface in a few hours, and implement the remaining interfaces in a day or so.
I want to make sure that if any error occurs during the database processing phase, program will know it need to roll back the whole process.
any good ORM in MFC/C++ for doing this ?
The MFC _ConnectionPtr object has BeginTrans, CommitTrans and RollbackTrans methods.
http://msdn.microsoft.com/en-us/library/ms675942(VS.85).aspx
I wouldn't call it good though, you'd need to wrap it.
This has nothing to do with ORM. You want basic transaction functionality
If you're using MFC, then most likely you're working with your database either via CDatabase (ODBC), CDaoWorkspace/CDaoDatabase (DAO), or CDataConnection/CSession (OLE DB). If so, you should use CDatabase::Rollback, CDaoWorkspace::Rollback, or CSession::Abort, respectively.
If you're connecting to a transactional database, like SQL Server, Oracle, PostgreSQL, Firebird, some of MySQL's data engines, etc. then they will have an API for transactions. Similarly, some non-SQL databases also have transactional semantics and an associated API (like Berkeley DB). Since you don't mention what database you're using, I really don't know what else to say.
Debea Database Library is an ORM for C++ - http://debea.net/
I'm wondering what kind of persistence solutions are there for C++ with a SQL database? In addition to doing things with custom SQL (and encapsulating the data access to DAOs or something similar), are there some other (more general) solutions?
Like some general libraries or frameworks (something like Hibernate & co for Java and .NET) or something else? (Something that I haven't even thought of can also be welcome to be suggested)
EDIT: Yep, I was searching more for an ORM solution or something similar to handle sql queries and the relationships between tables and objects than for the db engine itself. Thanks for all the answers anyway!
SQLite is great: it's fast, stable, proven, and easy to use and integrate.
There is also Metakit although the learning curve is a bit steep. But I've used it with success in a professional project.
It sounds like you are looking for some ORM so that you don't have to bother with hand written SQL code.
There is a post here that goes over ORM solutions for C++.
You also did not mention the type of application you are writing, if it is a desktop application, mobile application, server application.
Mobile: You are best off using SQLite as your database engine because it can be embedded and has a small footprint.
Desktop App: You should still consider using SQLite here, but you also have the option with most desktop applications to have an always on connection to the internet in which case you may want to provide a network server for this task. I suggest using Apache + MySQL + PHP and using a lightweight ORM such as Outlet ORM, and then using standard HTTP post calls to access your resources.
Server App: You have many more options here but I still suggest using Apache + MySQL + PHP + ORM because I find it is much easier to maintain this layer in a script language than in C++.
MySQL Connector/C++ is a C++ implementation of JDBC 4.0
The reference customers who use MySQL Connector/C++ are:
- OpenOffice - MySQL Workbench
Learn more: http://forums.mysql.com/read.php?167,221298
SQLite + Hiberlite is a nice and promising project. though I hope to see it more actively developed. see http : // code.google.com/p/hiberlite/
I use MYSQL or SQLite.
MYSQL: Provides a server based DB that your application must dynamically connect to.
SQLite:Provides an in memory or file base DB.
Using the in memory DB is useful for quick development as setting up and configuring a DB server just for a single project is a big task. But once you have a DB server up and running it's just as easy to sue that.
In memory DB is useful for holding small DB such as configuration etc.
While for larger data sets a DB server is probably more practical.
Download from here: http://dev.mysql.com/
Download from here: http://www.sqlite.org/