Arkadiy Vertleyb wrote:
[...] 1) The amount of feedback we have been receiving is unproportionaly lower than the amount of effort invested. This project started as kind of research rather than to fulfill the need of some concrete application. We hoped that, as we go, the applications would somehow emerge. After all the domain is pretty popular. Unfortunately this didn't seem to work.
The applications are there. But this is a domain in which most of the applications simply use the existing APIs, even if those are not C++- style APIs. Like sockets, threads, and everything else, we use a C API because that's what is available, but if a good C++ API were available, we would probably use that. So don't take the lack of strong demand to be an indicator that there is no demand. I absolutely guarantee that some relational db library in C++ is important, useful, and would find a large number of uses once it is created, validated, and made user-friendly.
2) The project turned out to be too ambitious for the two of us. We did implement all the functionality we wanted, but we could use a lot more testing, some parts might need to be re-written, re-designed, etc.
IOW, if there is an interest in this library, we need help. Let me know if anybody is interested, and to which extent -- I could open a project at sourceforge, and we could proceed from there... [...]
Unfortunately, I can cheer more than contribute. Obviously, there is a lot of interest in this type of library considering all the different projects that have been started. I personally find MySQL++ to be an abomination as far as support goes, and it is definitely an unfinished product, though it does some things really nicely. But that project also failed due to lack of resources. It seems to me that most Boost authors are not heavily involved in db-centric apps, which might explain the multitude of non-db-related libraries in Boost. But I think if all the different db-library authors were made aware of each other and conspired to work together, they could easily produce a Boost-quality db library, which I would like to see (and I'm sure many others would like to see as well). To reiterate what someone else said, one thing this library should almost certainly do is allow traversal of recordsets iterator-style, since that is The C++ Way (and It Is Good). Also, I think there is room for both statically-defined and dynamically-defined recordset types (think mapping to a predefined table or mapping to a query result set, possibly user-defined). I think a library that only offers one type is missing something important. If I only need to access raw tables for a db whose schema doesn't change, then I want statically defined recordsets to do so, without paying for any additional runtime burden. But I also want the ability to pass a raw SQL string to the library and possibly have it return a dynamically defined recordset with the appropriate fields included. That would be COOL. I, for one, use BDE, because BCB makes db access too easy for many apps. However, I would much rather use a C++ library if one were available. But it would need to be as easy to use as BDE/DAO/ADO to get me to switch, and I'm sure that is part of the reason for the slow adoption of libraries like RTL. You have a minimum usability barrier to cross before the user base will migrate to the library. Don't give up. DB apps are a huge portion of the market (possibly the biggest, I imagine), so I don't see how anyone who has done db work could think there isn't demand for good db libraries. The main problem, I think, is getting people to improve one good wheel instead of inventing many mediocre ones. Dave