On 28 March 2013 21:40, Vadim Zeitlin <[email protected]> wrote: > On Thu, 28 Mar 2013 15:18:30 +0000 Mateusz Loskot <[email protected]> wrote: > > ML> There has been interesting discussions about integer support > ML> and new tests lately and I'll follow up in relevant threads in details > soon. > ML> There is also lots of ideas and brainstorming about future plans: > ML> > ML> https://github.com/SOCI/soci/wiki/Roadmap > > BTW, something is broken on this page with "Complete support for C++ > integer types" not appearing under its own bullet point. I didn't fix this > myself because I thought that you could be still editing this page...
Fixed, thanks. > ML> There are three big things that will either require substantial > ML> amount of work or will introduce major changes: > ML> > ML> 1. Buried headers - major structural change > > I don't think it's as major as this. The only question is whether we want > to provide backwards compatibility or not. Personally I think that it's not > really difficult to do it so why not. I called it major, because I assume no backward compatibility. I gathered references to all buried headers patches here https://github.com/SOCI/soci/issues/25 Both attempts, Denis' and Julian's, include CMake option to contorl if SOCI headers are buried or not (Julian uses SOCI_HEADERS_NOT_BURIED and Denis uses SOCI_HEADERS_BURIED). I'm not convince we should keep SOCI 4 backward compatible, as there will be more changes that are likely going to break compatibility. And, efforts required to maintain backward compatible may stretch our capacity too much. But, I won't object if we want to keep 4 compatible with 3. There are two aspects of backward compatibility: one is simple control during compilation of SOCI and SOCI client apps which can be easy to achieve with those #ifdef's listed above; second is the package maintenance and "make install" - if we switch to buried headers, I don't think we want to keep installing headers into /usr/include directly, but into /usr/include/soci, so in fact we will have the headers buried regardless of use of SOCI_HEADERS_NOT_BURIED. > ML> 2. New tests > ML> > ML> 3. C++ integer types support > ML> > ML> Do we all agree to release those features in SOCI 4? > > This is the major stuff, yes. I'd also like to implement #51, already > mentioned in the roadmap, and work on tracing/error reporting Yes, I think we should work out consistent behaviour across all backends about what happens in cases like overflows or truncations, etc. I'm hoping to describe it in RFC1 sooner than later, that will make future end-user documentation too. > I didn't > have time to really think about it yet, so I'm not even sure if it's going > to be one thing or two but, in brief, I'd like to be able to: > > (a) Optionally log all SQL statements being sent to the database. > (b) Be able to show not only the text of failing request but also the > values of parameters used for it. > [...] I agree, so this would be a big fourth thing. Certainly, such detailed reporting is related to the integers support and even more related to new tests. > ML> Initially, having SVN experiences in mind, I thought it's > ML> important to do the buried headers and all structural > ML> changes first. > ML> Is my concern justified, shall we do the revolution first? > > Even if Git is capable of dealing with renamed/moved files, it's still > probably better to do this relatively quickly/atomically because even if > you can resolve conflicts resulting from moving a modified file, it doesn't > mean you want to or are are going to like doing it. Yes, so let's spawn new thread dedicated to the buried headers issue or simply discuss it in comments at GitHub and make this first change to happen. > ML> The branches will be most likely long-running branches, > ML> so I'd like to publish them in SOCI/soci repo, > ML> i.e. > ML> feature/buried-headers > > I'm really not sure why should this one be long-running... Am I missing > some extra difficulty here? No, you are not missing anything. It's that I assumed we will work on number of things at ones, and I may not be able to clear buried headers quickly within a day or two. Long story short, let's do buried headers first and keep all other pull requests and or coming changes pending until the buried headers have been completed. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html _______________________________________________ soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
