Hello, On 05/07/2011 14:52, Bruce Adams wrote:
> Firstly, when is the next release expected? Soon! For the very liberal interpretation of "soon". Technically speaking, there is no reason to wait with the release, it is just a matter of effort to do it. > Looking from the outside development seems to have stalled. The development has stalled, because SOCI has matured to the point of meeting the expectations of its main users. > However, I see there was a lot of activity around January towards releasing > v3.1. > What's remaining to be done? I believe that it is the actual package. > I can offer to do some basic testing of release candidates on redhat linux if > that helps. Thank you very much for the offer - the release candidate package will be announced first here before going public, so please just stay tuned. > What are the main targets for SOCI these days? I think it is fair to declare that the library officially supports those backends for which there is a known (and more or less active) maintainer. Of course, the whole project is driven my voluntary effort, so it is not possible to rely on such declarations, but this is the closest we can get. This means that currently the backends are like from the last release: Oracle, PostgreSQL and MySQL, on a variety of operating systems. > In my organisation some are pushing for JAVA for database use (& GUIs) and > C++ > for everything else. > I am looking to demonstrate that C++ is viable for database applications to > avoid a 2 language solution. I don't really understand. Database access is needed if an application requires the access to data in order to fulfill its purpose. There is no point in writing the client application that only performs database access - these accesses must be there for some reason. So, if you have a C++ application that needs to access the database, SOCI might be a good solution for you. Similarly, if you have a Java app that needs to access the database, then JDBC (or any framework like Spring, etc.) might be a good solution for you. Both languages have the capability to access the database and if you are working with some particular DB as the target (like Oracle), then this comes with its own client-side libraries as well. In other words, I don't understand why do you still have a language choice to make. > One more vaguely related question. What is the deal with boost? And what is the question? > I wonder if anyone could make a compelling case the case of using C++ for > database access rather than Java? There is no point in database access for its own sake. It must be there for a reason and that reason is very likely already tied to one language or another. Best regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
