On Sun, 27 May 2012 19:13:47 -0700 Pawel Aleksander Fedorynski <[email protected]> wrote:
PAF> This has been discussed several times on soci-users: PAF> PAF> http://sourceforge.net/mailarchive/message.php?msg_id=21455333 (search PAF> for "sequence") PAF> PAF> http://sourceforge.net/mailarchive/message.php?msg_id=21032224 PAF> PAF> http://sourceforge.net/mailarchive/message.php?msg_id=24476114 Thanks for the links! Reading them I understand better why Artyom has decided to start his own CppDB project... It really looks like a waste though, I'd have been very glad if he had implemented support for these features and cached prepared statements (which was my first feature request here too) several years ago. PAF> Long story short, there was some resistance from Maciej and others and PAF> the feature never got implemented. The objections seem to have all been of the form "you shouldn't use integer IDs at all". Which may be true or not, I really don't want to start discussing it as I'm definitely not a database expert, but it seems pretty presumptuous for SOCI to try to dictate how the application database should be structured. It should be just a tool instead of enforcing its developers opinions about the database design principles. PAF> FWIW i would have no objection to implementing such feature. OK, thanks, I'll push the changes out to https://github.com/vadz/soci-experiments when I finish (everything is already implemented but I didn't test all the backends yet). I also wonder where should the new methods be documented. The easy way is to just do it in the reference section, but nobody is probably going to find them there. But I don't see where else to put them, none of the existing sections (e.g. "Exchanging data" or "Statements, procedures and transactions") seem to fit and creating a new section just for this would be strange too as there is so little to say there. Any advice? Also, I'd welcome comments about the proposed API too. For the record, here are the new functions in soci::session: // Functions for dealing with sequence/auto-increment values. // If true is returned, value is filled with the next value from the given // sequence. Otherwise either the sequence is invalid (doesn't exist) or // the current backend doesn't support sequences. If you use sequences for // automatically generating primary key values, you should use // get_last_insert_id() after the insertion in this case. bool get_next_sequence_value(std::string const & sequence, long & value); // If true is returned, value is filled with the last auto-generated value // for this table (although some backends ignore the table argument and // return the last value auto-generated in this session). bool get_last_insert_id(std::string const & table, long & value); PAF> I personally don't think it would be useful since I don't believe in PAF> cross-database portability FWIW it does work rather well for us. Granted, we hardly push the database to its limits with the amounts of data we operate with, so it's perfectly possible that there are some performance problems that we're missing, but otherwise we don't have any problems. Regards, VZ
pgpTF4uP1c2CK.pgp
Description: PGP signature
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
