Hello, Koen Deforche wrote:
> I am not familiar with stored procedures, but would be interested if > this is a solution. > > How would that work? It would work by encapsulating your locking logic in terms of whatever code it takes to do it, and by returning a boolean flag stating whether it was done successfully. From the client perspective the call would look like any other statement that reads some boolean variable. > Do I have to implement this differently for every > database? Probably yes, because databases differ in their support for stored procedures. > Does every database support stored procedures? Probably not, which is the disadvantage if you plan to transparently target many database types in your application. > Would you consider accepting a patch for SOCI that adds this API call > and implements it for all the backends ? Of course and I would consult it with the rest of the team (which is reading this mailing list anyway). >> Isn't the above scenario a bit too low-level? > > I'm not sure I understand how this can be too low-level? What do you try to achieve with this locking technique? > I also believe that being integrated in boost will give SOCI a > perception of being more stable This is certainly very subjective and considering the fact that the current Boost effort to build a database access library is going nowhere, I do not even agree with it. Best regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
