Discussion:
[soci-users] The next three big things
Mateusz Loskot
2013-03-28 15:18:30 UTC
Permalink
Hi,

There has been interesting discussions about integer support
and new tests lately and I'll follow up in relevant threads in details soon.
There is also lots of ideas and brainstorming about future plans:

https://github.com/SOCI/soci/wiki/Roadmap

There are three big things that will either require substantial
amount of work or will introduce major changes:

1. Buried headers - major structural change
Perhaps it is good chance to
- rename headers .h to .hpp,
- introduce backend specific namespaces (see Roadmap)
- clean up the repo tree a bit, evict www to separate repository
- ???

2. New tests

3. C++ integer types support

Do we all agree to release those features in SOCI 4?

Initially, having SVN experiences in mind, I thought it's
important to do the buried headers and all structural
changes first.
Is my concern justified, shall we do the revolution first?

OTOH, it's Git, so we branching is effortless (tm).
We can branch off of develop and start working on
each of them in parallel.
Does anyone see any problem with that?

The branches will be most likely long-running
branches, so I'd like to publish them in SOCI/soci repo,
i.e.
feature/buried-headers
feature/new-tests
feature/cpp-integer
Then, everyone will be able to contribute with pull requests
against those branches, review, the code, etc.

Any comments on how we should proceed?


p.s. It looks, development discussions wiggle between soci-users
and soci-devel. I personally have no problem with use either or both.
But, if there are subscribers on soci-users list who do not wish to receive
posts related to development process, speak up please.
Then I'll ask to move such talks to soci-devel completely.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Sergei Nikulov
2013-03-28 15:34:16 UTC
Permalink
Post by Mateusz Loskot
Hi,
There has been interesting discussions about integer support
and new tests lately and I'll follow up in relevant threads in details soon.
https://github.com/SOCI/soci/wiki/Roadmap
There are three big things that will either require substantial
1. Buried headers - major structural change
Perhaps it is good chance to
- rename headers .h to .hpp,
- introduce backend specific namespaces (see Roadmap)
- clean up the repo tree a bit, evict www to separate repository
- ???
2. New tests
3. C++ integer types support
Do we all agree to release those features in SOCI 4?
Initially, having SVN experiences in mind, I thought it's
important to do the buried headers and all structural
changes first.
Is my concern justified, shall we do the revolution first?
OTOH, it's Git, so we branching is effortless (tm).
We can branch off of develop and start working on
each of them in parallel.
Does anyone see any problem with that?
The branches will be most likely long-running
branches, so I'd like to publish them in SOCI/soci repo,
i.e.
feature/buried-headers
feature/new-tests
feature/cpp-integer
Then, everyone will be able to contribute with pull requests
against those branches, review, the code, etc.
Any comments on how we should proceed?
p.s. It looks, development discussions wiggle between soci-users
and soci-devel. I personally have no problem with use either or both.
But, if there are subscribers on soci-users list who do not wish to receive
posts related to development process, speak up please.
Then I'll ask to move such talks to soci-devel completely.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Here the database interface proposal
http://isocpp.org/files/papers/n3612.pdf
I think we can pick something from this paper.
--
Best Regards,
Sergei Nikulov
Bruce Adams
2013-04-02 11:53:40 UTC
Permalink
Hi,
    One key thing missing from N3612 is object relational mapping. It is not appropriate in all cases but it does make working
with databases so much more convenient. Low level access should be possible (though sometimes I question this) but not required.

Regards,

Bruce.
Post by Mateusz Loskot
________________________________
Sent: Thursday, March 28, 2013 3:34 PM
Subject: Re: [soci-users] The next three big things
Hi,
Post by Mateusz Loskot
There has been interesting discussions about integer support
and new tests lately and I'll follow up in relevant threads in details soon.
https://github.com/SOCI/soci/wiki/Roadmap
There are three big things that will either require substantial
1. Buried headers - major structural change
Perhaps it is good chance to
- rename headers .h to .hpp,
- introduce backend specific namespaces (see Roadmap)
- clean up the repo tree a bit, evict www to separate repository
- ???
2. New tests
3. C++ integer types support
Do we all agree to release those features in SOCI 4?
Initially, having SVN experiences in mind, I thought it's
important to do the buried headers and all structural
changes first.
Is my concern justified, shall we do the revolution first?
OTOH, it's Git, so we branching is effortless (tm).
We can branch off of develop and start working on
each of them in parallel.
Does anyone see any problem with that?
The branches will be most likely long-running
branches, so I'd like to publish them in SOCI/soci repo,
i.e.
feature/buried-headers
feature/new-tests
feature/cpp-integer
Then, everyone will be able to contribute with pull requests
against those branches, review, the code, etc.
Any comments on how we should proceed?
p.s. It looks, development discussions wiggle between soci-users
and soci-devel. I personally have no problem with use either or both.
But, if there are subscribers on soci-users list who do not wish to receive
posts related to development process, speak up please.
Then I'll ask to move such talks to soci-devel completely.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Here the database interface proposal http://isocpp.org/files/papers/n3612.pdf
I think we can pick something from this paper.
--
Best Regards,
Sergei Nikulov
------------------------------------------------------------------------------
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
_______________________________________________
soci-users mailing list
https://lists.sourceforge.net/lists/listinfo/soci-users
Viacheslav Naydenov
2013-04-03 12:13:49 UTC
Permalink
Did you mean there should or could be an ultimate ORM interface to promote as a standard into C++?
Though I doubt this is feasible, I agree with you, that a higher level of interaction with DB may be preferred.
What ORM solutions for C++ are you familiar with?
If you feel this question is a bit off topic, you can answer me direclty.
Post by Bruce Adams
Hi,
    One key thing missing from N3612 is object relational mapping. It is not appropriate in all cases but it does make working
with databases so much more convenient. Low level access should be possible (though sometimes I question this) but not required.
Regards,
Bruce.
Post by Mateusz Loskot
----------------------------------------
Sent: Thursday, March 28, 2013 3:34 PM
Subject: Re: [soci-users] The next three big things
Post by Mateusz Loskot
Hi,
There has been interesting discussions about integer support
and new tests lately and I'll follow up in relevant threads in details soon.
https://github.com/SOCI/soci/wiki/Roadmap
There are three big things that will either require substantial
1. Buried headers - major structural change
Perhaps it is good chance to
- rename headers .h to .hpp,
- introduce backend specific namespaces (see Roadmap)
- clean up the repo tree a bit, evict www to separate repository
- ???
2. New tests
3. C++ integer types support
Do we all agree to release those features in SOCI 4?
Initially, having SVN experiences in mind, I thought it's
important to do the buried headers and all structural
changes first.
Is my concern justified, shall we do the revolution first?
OTOH, it's Git, so we branching is effortless (tm).
We can branch off of develop and start working on
each of them in parallel.
Does anyone see any problem with that?
The branches will be most likely long-running
branches, so I'd like to publish them in SOCI/soci repo,
i.e.
feature/buried-headers
feature/new-tests
feature/cpp-integer
Then, everyone will be able to contribute with pull requests
against those branches, review, the code, etc.
Any comments on how we should proceed?
p.s. It looks, development discussions wiggle between soci-users
and soci-devel. I personally have no problem with use either or both.
But, if there are subscribers on soci-users list who do not wish to receive
posts related to development process, speak up please.
Then I'll ask to move such talks to soci-devel completely.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Here the database interface proposal http://isocpp.org/files/papers/n3612.pdf
I think we can pick something from this paper.
--
Best Regards,
Sergei Nikulov
------------------------------------------------------------------------------
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
_______________________________________________
soci-users mailing list
https://lists.sourceforge.net/lists/listinfo/soci-users
,
------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
,
_______________________________________________
soci-users mailing list
https://lists.sourceforge.net/lists/listinfo/soci-users
--
Best regards,
Viacheslav Naydenov.
Bruce Adams
2013-04-03 21:34:16 UTC
Permalink
Hi,
    I don't think its at all off topic. Essentially yes I believe that just as hibernate (amongst others) led to the JPA for java the C++ community should
aim to provide something as standard in C++. I recall SOCI has some ORM features but when I last reviewed them they were less mature than those in the database template library (DTL). SOCI has seen a flurry of development since then but I don't know how much of that has focused on the ORM side. DTL provides an elegant and easy to use ORM solution but on the other hand has less of the low level access features that SOCI development has been keen to focus on. I suppose I was aiming to minimise my exposure to SQL rather than find a safer way to embed it in C++. But perhaps the crux of the argument would be that it should be possible to have the schema of a class reflect the table's schema and create an object that maps to the table such that the objects read methods query the table and its update method insert to it. DTL does this so well that the class may in fact represent a join or indeed any query and still allow you to read or write as if you are
reading or writing
a non-persistent data structure (of course you aren't so you have to wary of that).

Regards,

Bruce.
Post by Mateusz Loskot
________________________________
Sent: Wednesday, April 3, 2013 1:13 PM
Subject: Re: [soci-users] The next three big things
Did you mean there should or could be an ultimate ORM interface to promote as a standard into C++?
Though I doubt this is feasible, I agree with you, that a higher level of interaction with DB may be preferred.
What ORM solutions for C++ are you familiar with?
If you feel this question is a bit off topic, you can answer me direclty.
Post by Bruce Adams
Hi,
    One key thing missing from N3612 is object relational mapping. It is not appropriate in all cases but it does make working
with databases so much more convenient. Low level access should be possible (though sometimes I question this) but not required.
Regards,
Bruce.
Post by Mateusz Loskot
----------------------------------------
Sent: Thursday, March 28, 2013 3:34 PM
Subject: Re: [soci-users] The next three big things
Post by Mateusz Loskot
Hi,
There has been interesting discussions about integer support
and new tests lately and I'll follow up in relevant threads in details soon.
https://github.com/SOCI/soci/wiki/Roadmap
There are three big things that will either require substantial
1. Buried headers - major structural change
Perhaps it is good chance to
- rename headers .h to .hpp,
- introduce backend specific namespaces (see Roadmap)
- clean up the repo tree a bit, evict www to separate repository
- ???
2. New tests
3. C++ integer types support
Do we all agree to release those features in SOCI 4?
Initially, having SVN experiences in mind, I thought it's
important to do the buried headers and all structural
changes first.
Is my concern justified, shall we do the revolution first?
OTOH, it's Git, so we branching is effortless (tm).
We can branch off of develop and start working on
each of them in parallel.
Does anyone see any problem with that?
The branches will be most likely long-running
branches, so I'd like to publish them in SOCI/soci repo,
i.e.
feature/buried-headers
feature/new-tests
feature/cpp-integer
Then, everyone will be able to contribute with pull requests
against those branches, review, the code, etc.
Any comments on how we should proceed?
p.s. It looks, development discussions wiggle between soci-users
and soci-devel. I personally have no problem with use either or both.
But, if there are subscribers on soci-users list who do not wish to receive
posts related to development process, speak up please.
Then I'll ask to move such talks to soci-devel completely.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Here the database interface proposal http://isocpp.org/files/papers/n3612.pdf
I think we can pick something from this paper.
--
Best Regards,
Sergei Nikulov
------------------------------------------------------------------------------
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
_______________________________________________
soci-users mailing list
https://lists.sourceforge.net/lists/listinfo/soci-users
,
------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
,
_______________________________________________
soci-users mailing list
https://lists.sourceforge.net/lists/listinfo/soci-users
--
Best regards,
Viacheslav Naydenov.
Ricardo Fabiano de Andrade
2013-03-28 17:07:23 UTC
Permalink
My comments in blue.
Best regards,
Ricardo Andrade
Post by Mateusz Loskot
Hi,
There has been interesting discussions about integer support
and new tests lately and I'll follow up in relevant threads in details soon.
https://github.com/SOCI/soci/wiki/Roadmap
There are three big things that will either require substantial
1. Buried headers - major structural change
Perhaps it is good chance to
- rename headers .h to .hpp,
- introduce backend specific namespaces (see Roadmap)
- clean up the repo tree a bit, evict www to separate repository
- ???
2. New tests
3. C++ integer types support
I agree with the order of the things.
Do we all agree to release those features in SOCI 4?
Initially, yes. According to the deadline, more can be included.
Initially, having SVN experiences in mind, I thought it's
important to do the buried headers and all structural
changes first.
Is my concern justified, shall we do the revolution first?
OTOH, it's Git, so we branching is effortless (tm).
We can branch off of develop and start working on
each of them in parallel.
Does anyone see any problem with that?
IMO, it's completely feasible doing multiple things at once in separate
branches.
3. can be done over the existing tree structure and then merged into the
new one.
I don't see any potential issues in this approach.
2. can follow the same direction. Upgrade the tests to the new framework
first.
Then migrate it to the new structure. This choice have the added bonus of
forcing us to make the *same tests* work in both old and new tree
structures.
Post by Mateusz Loskot
The branches will be most likely long-running
branches, so I'd like to publish them in SOCI/soci repo,
i.e.
feature/buried-headers
feature/new-tests
feature/cpp-integer
Then, everyone will be able to contribute with pull requests
against those branches, review, the code, etc.
I also agree with this approach to the repos.
Any comments on how we should proceed?
p.s. It looks, development discussions wiggle between soci-users
and soci-devel. I personally have no problem with use either or both.
But, if there are subscribers on soci-users list who do not wish to receive
posts related to development process, speak up please.
Then I'll ask to move such talks to soci-devel completely.
I think we should switch to soci-devel, for the sake of a better
organization.

Even though soci users probably understand all the dev discussions, it's a
completely different mindset. They are probably looking for better ways to
solve their daily duties using current versions of soci and not specially
interested in what comes next (and how that will happen).

In the other hand, soci-devel subscribers may want to prioritize mail
coming from this list what is not possible while using a single mail list.

I know that having devs discussion over the soci-users might serve as a
kind of self advertisement, so users know what's going on and how active is
the project.

However, I think this is a maintainers' job. They should bring the best
things discussed of the soci-devel to the soci-users to catch the attention
of the users. This also serve as a filter of the bad things (no one wants
to know how the politics is done). :-)

My two cents.

Best regards,
Post by Mateusz Loskot
--
Mateusz Loskot, http://mateusz.loskot.net
------------------------------------------------------------------------------
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
_______________________________________________
soci-users mailing list
https://lists.sourceforge.net/lists/listinfo/soci-users
Vadim Zeitlin
2013-03-28 21:40:32 UTC
Permalink
On Thu, 28 Mar 2013 15:18:30 +0000 Mateusz Loskot <***@loskot.net> 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...

[update: I started writing this in the afternoon but got preempted by other
things, so you are probably not editing it any more by now, when I
finally send it]

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.

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. 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.

The last one is especially important as currently our application can give
error messages of the form

Violation of PRIMARY or UNIQUE KEY constraint "unique_foo_bar"
on table "table_name" while executing
"insert into table_name(foo, bar) values (:foo, :bar)"

which is singularly unhelpful -- we really need to have the values this
statement was executed with and not just the placeholders.


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.

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?

Thanks,
VZ
Alex Ott
2013-03-29 09:59:35 UTC
Permalink
Hi

Regarding error handling - it would be nice to have some common set of
error codes (enum?) propagated together with exception - in my app I
don't know which database will be supported until runtime (I link only
core, and modules are loaded dynamically), so I can't link specific DB
modules to get DB-specific exceptions. What I can see right now,
something like:
- Connection exceptions:
- server isnt' available
- authorization error
- ...
- Query/commands exceptions:
- bad command
- permission error
- ....

What do you think?
Post by Vadim Zeitlin
This is the major stuff, yes. I'd also like to implement #51, already
mentioned in the roadmap, and work on tracing/error reporting. I didn't
have time to really think about it yet, so I'm not even sure if it's going
(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.
The last one is especially important as currently our application can give
error messages of the form
Violation of PRIMARY or UNIQUE KEY constraint "unique_foo_bar"
on table "table_name" while executing
"insert into table_name(foo, bar) values (:foo, :bar)"
which is singularly unhelpful -- we really need to have the values this
statement was executed with and not just the placeholders.
--
With best wishes, Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)
Skype: alex.ott
Ricardo Fabiano de Andrade
2013-03-29 12:13:37 UTC
Permalink
What would be better? Error codes or a more detailed exception hierarchy? A
mix?
Post by Alex Ott
Hi
Regarding error handling - it would be nice to have some common set of
error codes (enum?) propagated together with exception - in my app I
don't know which database will be supported until runtime (I link only
core, and modules are loaded dynamically), so I can't link specific DB
modules to get DB-specific exceptions. What I can see right now,
- server isnt' available
- authorization error
- ...
- bad command
- permission error
- ....
What do you think?
Post by Vadim Zeitlin
This is the major stuff, yes. I'd also like to implement #51, already
mentioned in the roadmap, and work on tracing/error reporting. I didn't
have time to really think about it yet, so I'm not even sure if it's
going
Post by Vadim Zeitlin
(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.
The last one is especially important as currently our application can
give
Post by Vadim Zeitlin
error messages of the form
Violation of PRIMARY or UNIQUE KEY constraint "unique_foo_bar"
on table "table_name" while executing
"insert into table_name(foo, bar) values (:foo, :bar)"
which is singularly unhelpful -- we really need to have the values this
statement was executed with and not just the placeholders.
--
With best wishes, Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)
Skype: alex.ott
------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
soci-users mailing list
https://lists.sourceforge.net/lists/listinfo/soci-users
Mateusz Loskot
2013-04-04 09:33:32 UTC
Permalink
Post by Alex Ott
Regarding error handling - it would be nice to have some common set of
error codes (enum?) propagated together with exception
I think it's a good idea to to try to unify errors.
Post by Alex Ott
- in my app I
don't know which database will be supported until runtime (I link only
core, and modules are loaded dynamically), so I can't link specific DB
modules to get DB-specific exceptions.
I have overlooked this very good point. Likely, because I don't use
dynamically loaded backends myself.

I was hoping the paper linked by Sergei [1] would suggest a neat
solution, but it only states what we already know:
"it is not trivial to implement, as there exists a database state this is
coupled with but separate from the application state".

[1] http://isocpp.org/files/papers/n3612.pdf

I haven't given lots of thoughts on how to improve exceptions in SOCI.
Briefly, I see several approaches:
1) never carry database session state in exception object, but compose
complete exception before throwing
2) carry database state, i.e. SOCI backend

I also wonder if we could learn a lesson from C++11 features like
std::error_category and std::error_code to model SOCI errors.
If we don't switch to C++11 for SOCI 4, we could use Boost.System.

Thoughts?

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Bruce Adams
2013-04-12 15:16:59 UTC
Permalink
Thanks in part to my prompting the the author of DTL has posted in regard to n3612

https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/iqOtgxP_IRA

One of the attractions of DTLs approach for me is illustrated by the example of how to dump an entire table:


DynamicDBView<> view("DB_EXAMPLE", "*"); 
copy(view.begin(), view.end(), ostream_iterator<variant_row>(cout, "\n"));

I never worked out if it was possible to be quite so elegant in SOCI. Is it?
Post by Mateusz Loskot
________________________________
Sent: Thursday, April 4, 2013 10:33 AM
Subject: Re: [soci-users] The next three big things
Post by Alex Ott
Regarding error handling - it would be nice to have some common set of
error codes (enum?) propagated together with exception
I think it's a good idea to to try to unify errors.
Post by Alex Ott
- in my app I
don't know which database will be supported until runtime (I link only
core, and modules are loaded dynamically), so I can't link specific DB
modules to get DB-specific exceptions.
I have overlooked this very good point. Likely, because I don't use
dynamically loaded backends myself.
I was hoping the paper linked by Sergei [1] would suggest a neat
"it is not trivial to implement, as there exists a database state this is
coupled with but separate from the application state".
[1] http://isocpp.org/files/papers/n3612.pdf
I haven't given lots of thoughts on how to improve exceptions in SOCI.
1) never carry database session state in exception object, but compose
complete exception before throwing
2) carry database state, i.e. SOCI backend
I also wonder if we could learn a lesson from C++11 features like
std::error_category and std::error_code to model SOCI errors.
If we don't switch to C++11 for SOCI 4, we could use Boost.System.
Thoughts?
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
https://lists.sourceforge.net/lists/listinfo/soci-users
Mateusz Loskot
2013-04-12 16:48:35 UTC
Permalink
Post by Bruce Adams
Thanks in part to my prompting the the author of DTL has posted in regard to n3612
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/iqOtgxP_IRA
Thanks for that. The whole discussion is very interesting.
I will yet see, but despite I am subscribed to that mailing list,
it is unlikely I will have time to dive into it myself, unfortunately.
Post by Bruce Adams
One of the attractions of DTLs approach for me is illustrated by the example
DynamicDBView<> view("DB_EXAMPLE", "*");
copy(view.begin(), view.end(), ostream_iterator<variant_row>(cout, "\n"));
I never worked out if it was possible to be quite so elegant in SOCI. Is it?
Yes, fancy :-)
Bruce Adams
2013-04-12 17:44:45 UTC
Permalink
Hi
   Oops I should have RTFMed a bit more to refresh my memory before posting.

There are some significant differences.
To start things off (excuse errors due to failure to RTFM sufficiently):

DTL auto-prepares statements (would you ever not want to do this?)

You don't need to say select or insert its implicit in whether you are reading or writing.

So you just specify one or more tables (joins just work!)


There's also a bulk fetch helper which can be used more efficiently than iteration.

Its not clear to me when SOCI uses bulk fetch. If you use a vector of rows I think it will just iterate?


Finally there is fine control over the mapping of datatypes (for reasons I forget called a BCA in DTL,
 and which in C++11 could be a lambda instead).
I think this is a little less awkward than specialising the type_conversion template in SOCI
(though I am prepared to be shown wrong by any SOCI gurus)

E.g.

      MyRowType rowbuf,

      DBView<MyRowType> view("table1, table1",
                                                  BCA(rowbuf,
                                                           COLS["column1"] >> rowbuf.column1 &&
                                                           COLS["column2"] >> rowbuf.column2),
                                                 "where clause here if you want it");

      bulk_fetch_helper(view.begin(), 500, std::ostream_iterator<MyRowType>(std::cout, "\n"));


So I think there is some room for improvement in SOCI on the ORM side.

I suspect a lot of the success of SOCI, in terms of attracting users, is based on its ability to make queries look
like embedded SQL (but of course so much better).

I think the success of ORMs and DTL in particular is in hiding the database wherever possible.

So from the ORM perspective embedding SQL seems like a horseless carriage
(see for example http://www.horton.com/beyondhcthandouts.htm)

The DTL documentation makes no bones about pushing for a modern design away from the horseless carriage of embedded SQL.
SOCI on the other hand just leaves it to the user. Users coming from the a background of using SQL directly on the database
will naturally be drawn to the embedded SQL way of thinking and hence prefer that side of SOCI to its ORM offering.

Java programmers will be drawn the other way from using Hibernate/JPA.

My agenda here is simply that SOCI+DTL (or even +=) would form a good starting point for a standard C++ database interface.
Now that its come up again in the context of C++1y with library proposals not having to wait for a new standard
its worth giving more thought.

Regards,

Bruce.
Post by Mateusz Loskot
________________________________
Sent: Friday, April 12, 2013 5:48 PM
Subject: Re: [soci-users] The next three big things
Post by Bruce Adams
Thanks in part to my prompting the the author of DTL has posted in regard to n3612
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/iqOtgxP_IRA
Thanks for that. The whole discussion is very interesting.
I will yet see, but despite I am subscribed to that mailing list,
it is unlikely I will have time to dive into it myself, unfortunately.
Post by Bruce Adams
One of the attractions of DTLs approach for me is illustrated by the example
DynamicDBView<> view("DB_EXAMPLE", "*");
copy(view.begin(), view.end(), ostream_iterator<variant_row>(cout, "\n"));
I never worked out if it was possible to be
Mateusz Loskot
2013-04-12 21:13:36 UTC
Permalink
Post by Bruce Adams
DTL auto-prepares statements (would you ever not want to do this?)
If I need it, I may consider myself to implement it.
If someone needs it, implements it, then (s)he should feel
free to submit it to SOCI.
Post by Bruce Adams
You don't need to say select or insert its implicit in whether you are reading or writing.
So you just specify one or more tables (joins just work!)
That is significant conceptual difference between SOCI and DTL.
In SOCI, that's also AFAIU the historical legacy, query in textual form plays
important role as a glue that frees us from implementing SQL variants
within the library.
Post by Bruce Adams
There's also a bulk fetch helper which can be used more efficiently than iteration.
Its not clear to me when SOCI uses bulk fetch. If you use a vector of rows I
think it will just iterate?
for all std::vector<T> where T is C++ intrinsic type which SOCI
declares to support
(see docs). Actual realisation of bulk statements is DBMS-specific.
Post by Bruce Adams
Finally there is fine control over the mapping of datatypes (for reasons I
forget called a BCA in DTL, and which in C++11 could be a lambda instead).
AFAIK, DTL is highly ORM-oriented,
whereas SOCI offers ORM as "one of" feature.
Post by Bruce Adams
I think this is a little less awkward than specialising the type_conversion
template in SOCI
(though I am prepared to be shown wrong by any SOCI gurus)
It should be possible to provide automatic type registration to adapt
user-defined types automagically. For example, in Boost.Geometry lib
I use this technique:
http://www.boost.org/doc/libs/1_51_0/boost/geometry/geometries/register/point.hpp

Besides, we have Boost.Fusion support that should do the job quite well.
Post by Bruce Adams
E.g.
MyRowType rowbuf,
DBView<MyRowType> view("table1, table1",
BCA(rowbuf,
COLS["column1"]
Post by Bruce Adams
rowbuf.column1 &&
COLS["column2"]
Post by Bruce Adams
rowbuf.column2),
"where clause here if you
want it");
bulk_fetch_helper(view.begin(), 500,
std::ostream_iterator<MyRowType>(std::cout, "\n"));
Paraphrasing a British diplomatic answer: "it looks, hmm, interesting" :)
Post by Bruce Adams
So I think there is some room for improvement in SOCI on the ORM side.
Sure, there is, but I'd rather wait for C++11 adoption and follow
Roland Bock's idea as presented here:
http://article.gmane.org/gmane.comp.lib.boost.devel/238774

Note, this kind of ideas have been discussed within Boost community
a few years ago already:
http://lists.boost.org/Archives/boost/2010/09/170983.php

I have an impression that lots of ideas have been held back and postponed
until C++11 is published as it opens whole new capabilities in C++
and we shall expect spring of new C++11-only libraries in near future
(i.e. Boost.Spirit 3).
Post by Bruce Adams
I suspect a lot of the success of SOCI, in terms of attracting users, is
based on its ability to make queries look
like embedded SQL (but of course so much better).
I think the success of ORMs and DTL in particular is in hiding the database
wherever possible.
So from the ORM perspective embedding SQL seems like a horseless carriage
(see for example http://www.horton.com/beyondhcthandouts.htm)
Yes, it fits very well into the paradigm of OOP in terms of which we
all like to think
and allows users to actually forget they speak to a database.
IMO, ORM is a higher level problem and even the fanciest ORM DSL won't help
much if the things are screwed at lower level (like basic types conversions,
incomplete implementation of backends, semantic/behaviour incompatibilities
between backends, etc.)
Post by Bruce Adams
The DTL documentation makes no bones about pushing for a modern design away
from the horseless carriage of embedded SQL.
SOCI on the other hand just leaves it to the user. Users coming from the a
background of using SQL directly on the database
will naturally be drawn to the embedded SQL way of thinking and hence prefer
that side of SOCI to its ORM offering.
Java programmers will be drawn the other way from using Hibernate/JPA.
We can't fulfil everyone's expectations, I'm afraid.
Post by Bruce Adams
My agenda here is simply that SOCI+DTL (or even +=) would form a good
starting point for a standard C++ database interface.
Generally, yes. In practice, there won't be anything like "great,
let's merge our projects".
I'm 99% sure if std::database happens, it will be designed and written from
scratch completely without looking back. There won't be any code reuse or
copying, merging, facading, adapting, and so on.
Bootstrapping will happen.

Best regards
--
Mateusz Loskot, http://mateusz.loskot.net

Mateusz Loskot
2013-04-03 12:43:10 UTC
Permalink
Post by Vadim Zeitlin
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>
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.
Post by Vadim Zeitlin
ML> There are three big things that will either require substantial
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.
Post by Vadim Zeitlin
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.
Post by Vadim Zeitlin
I didn't
have time to really think about it yet, so I'm not even sure if it's going
(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.
Post by Vadim Zeitlin
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.
Post by Vadim Zeitlin
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
Loading...