----- Original Message ---- > From: Maciej Sobczak <[email protected]> > To: General-purpose list for SOCI users. <[email protected]> > Sent: Tue, July 5, 2011 11:20:02 PM > Subject: Re: [SOCI-users] Questions > > 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. > The application is actually made of multiple small programs currently in any of several languages, including one that should have been retired a long time ago (along with punch cards). The current trend is for C++ and Java programs. There is a belief that java is suited for database stuff and C++ is faster. I believe both of those beliefs are misguided and not the reason to choose one language over the other. I also favour minimising the number of languages used. I have a component (suite of programs) written in C++ which currently makes no use of the database. There is a development policy that implies that I should introduce java if I want to talk to the database. To my mind that is not a good enough reason to require supporting an extra language. The reason for the policy is simply that the organisation has some okay experience with hibernate but little with database access in C++. The logic is flawed but backed by management a few sample programs could demonstrate
it as flawed in a way harder to refute. I also want to use something higher level than client side libraries and stay database independent where possible. For example, we are currently using oracle for the sole reason that we always have. Oracle is not cheap and we could save a fortune if we got rid of it. My experience of it so far is that it is generally poorer quality than mysql & postgresql. Perhaps it scales better but I have seen no evidence of that. > > One more vaguely related question. What is the deal with boost? > > And what is the question? Someone on this list made an off hand comment which seemed to imply the folk at boost would be unwilling to accept SOCI. Plus the discussion some years ago and the obvious gap in boost where a database library should be made me wonder why SOCI or something else still hasn't filled that gap. > > > 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. > You are right. However the reason is COBOL! So lets not go there! It is a re-writing effort that has splintered things "interestingly" > 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 > ------------------------------------------------------------------------------ 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
