On Mon, 28 May 2012 10:29:06 -0700 Pawel Aleksander Fedorynski <[email protected]> wrote:
PAF> > I also wonder where should the new methods be documented. The easy way is PAF> > to just do it in the reference section, but nobody is probably going to PAF> > find them there. But I don't see where else to put them, none of the PAF> > existing sections (e.g. "Exchanging data" or "Statements, procedures and PAF> > transactions") seem to fit and creating a new section just for this would PAF> > be strange too as there is so little to say there. Any advice? PAF> PAF> I'd make it a separate section. Doesn't have to be long. OK, I'll do this, thanks. PAF> > // Functions for dealing with sequence/auto-increment values. PAF> > PAF> > // If true is returned, value is filled with the next value from the given PAF> > // sequence. Otherwise either the sequence is invalid (doesn't exist) or PAF> > // the current backend doesn't support sequences. If you use sequences for PAF> > // automatically generating primary key values, you should use PAF> > // get_last_insert_id() after the insertion in this case. PAF> > bool get_next_sequence_value(std::string const & sequence, long & value); PAF> > PAF> > // If true is returned, value is filled with the last auto-generated value PAF> > // for this table (although some backends ignore the table argument and PAF> > // return the last value auto-generated in this session). PAF> > bool get_last_insert_id(std::string const & table, long & value); PAF> PAF> Looks good. I would prefer pointers instead of non-const reference PAF> parameters but we should do whatever's consistent with the rest of PAF> SOCI. Well, yes, this is exactly the point. I also dislike non-const references and don't use it in my own projects but I'm just trying to be consistent here as I think it's even more important. If there is a consensus to switch from this style and start using pointers for output parameters, I'd be glad to change this but otherwise I'll leave this like this. I also have a question about implementation: for most of the backends I actually use soci::session to execute some sort of select in the database. This is a bit strange as currently the session uses the backends but not vice versa but OTOH it makes the code very simple and short. And to avoid this dependency (of the backend on the session) I'd need to actually duplicate the code from backend/foo/statement.cpp because I can't even reuse a foo_statement_backend without soci::session, i.e. without the dependency I'd like to avoid. IMHO duplicating the code would be even worse than having this reverse dependency. The best solution would be to refactor foo_statement_backend to allow reusing parts of it from foo_session_backend without involving soci::session itself, but I don't really have resources for this... So I only see the two choices described above and for now I chose the simplest one (if laziness is the main virtue of a programmer, I'm a good one). Does anybody see any problem with leaving it like this or any better suggestions? Thanks, VZ
pgpD3nJqNfchu.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
