On 31 October 2012 14:30, Vadim Zeitlin <[email protected]> wrote: > On Wed, 31 Oct 2012 09:49:54 -0400 Candy Chiu <[email protected]> wrote: > > CC> Vadim removed convert_from_base() from standard_use_type. However, it > CC> still exists in use_type<values>. It is causing an issue in insert > queries > CC> that also return the auto increment id into the domain. > CC> > CC> Student t = createStudent(); > CC> statement st = (sql.prepare > CC> << "insert into Student (firstname, email, age, groupId, weight) " > CC> << " OUTPUT inserted.Id " > CC> << "values (:firstname, :email, :age, :groupId, :weight) " > CC> , into(student.Id), > CC> , use(student)); > CC> > CC> The convert_from_base() in post_use overwrites the data returned into > CC> student.Id. > > I'm sorry, I didn't use use_type<value> in my own code yet so I don't know > how does it work precisely. But FWIW I agree that from the general point of > view the call to convert_from_base() here should be removed too because I > believe convert_from_base() should only be called in post_fetch(), i.e. > only used for out "into" parameters and never for the "use" ones.
Actually, that is my understanding too. > It would be definitely nice to document convert_from_base() and > convert_to_base() better and clearly describe what exactly are they > supposed to do and when should they be called because there is a lot of > confusion about them, see all the commented out calls to convert_to_base(). I agree, and I'm hoping to update the docs and clarify number of things as soon as we are ready for new release, regardless it will be minor or major. Another confusing example for me is clean_up() semantic, comparing current uses of it with the backend reference raises questions :) > I could probably do it according to my understanding but it could be > incomplete, so there is a real danger of breaking something which is why I > preferred to not touch this so far. But I could at least remove the call to > convert_from_base() in use_type<value> if there are no objections. > > Are there? I have no objects, but I have two issues, in PostgreSQL [1] and SQLite3 [2], which are loom large in in my mind at the moment. Thus, as long as I don't see all SOCI tests green, I'm unsure about any serious changes, otherwise it may be difficult to get things back in order. But, I'd encourage anyone who's willing to contribute the clean-up around convert_from_base to go for it and submit a pull request. And, IMHO, if such changes won't break the tests any worse than they are currently broken (two tests failing, for [1] and [2]), then are fine, I guess. [1] https://github.com/SOCI/soci/issues/13 [2] https://github.com/SOCI/soci/issues/15 p.s. I haven't officially announced the switch to GitHub, but the fact is, we've already moved development there, so please, feel free to make use of it. An official announcement is on its way, once I have got GH accounts from all developers. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
