On Mon, May 28, 2012 at 5:19 AM, Vadim Zeitlin <[email protected]> wrote: > 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.
I agree. > 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). Thank you Vadim! > 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? I'd make it a separate section. Doesn't have to be long. > > 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); Looks good. I would prefer pointers instead of non-const reference parameters but we should do whatever's consistent with the rest of SOCI. > 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. Well since you're happily doing it then obviously I'm wrong. When I used to develop database-backed applications it felt a day never went by without using some non-portable SQL syntax that was necessary to do what I wanted. Thank you again for working on this. Best regards, Aleksander ------------------------------------------------------------------------------ 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
