|
| Re: SQL handling in CDO [message #111815 is a reply to message #111807] |
Tue, 05 February 2008 18:36  |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Hi Stefan,
You're pretty right and there's already https://bugs.eclipse.org/bugs/show_bug.cgi?id=214487 for this issue. I've even committed preparation work for it (see IDBStatement).
There have been 2 reasons for the StringBuilder design:
- Currently the DBStore can only work in auditing mode which means that rows are never updated (well mostly) but rather reinserted to preserve the old state. In non-auditing (and delta-support) mode the needed update statements would depend on the actual deltas. For a single table htere would be many different update statements possible. I simply was unsure about the overhead of creating so many prepared statements. This is why I spent effort for a small DML framework that abstracts away the concrete decision of whether to use prepared or unprepared statements.
- I was always a bit unsure how connection pools cope with vast numbers of prepared statements. There's already https://bugs.eclipse.org/bugs/show_bug.cgi?id=216586 with a little preparation work for this issue.
Comments or recommendations for these topics are greatly appreciated ;-)
Although these topics are not "dead" I decidied to postpone all work on the native DBStore in favour of developing the new HibernateStore together with Martin. This will be ineresting especially for you since you don't need the auditing mode (which I suspect will not be supported by the HibernateStore in a first run).
Cheers
/Eike
Stefan Winkler schrieb:
> Hi Eike,
>
> I created a patch to my bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=217255 which fixes the
> date issues in mysql.
> When I was debugging to find out where the objects and revisions are
> retrieved I found out that you store objects using the stringbuilder to
> create the complete SQL statement, but you use the JDBC
> ResultSet.getXxx() methods to retrieve values.
>
> Why is that? Storing the date using a JDBC Statement together with
> ?-Placeholders and set-methods like setTimestamp would have been easier
> and more error-proof than the stringbuilding thing (also it would make
> db-adapters smaller, as most of the appendValue-logic is already
> implemented in JDBC).
> The problem is also, that it is a bit unclear how the MySQL JDBC-driver
> handles timezones. So expect timezones not to work with my patch above ...
>
> I would open a bug for the stringbuilder <-> JDBC inconsistence, because
> I think this is a design problem. However, the changes would be rather
> large and I guess the Teneo-CDO-integration will replace the CDO
> relational mapping anyway, eventually eliminating potential issues.
>
> Cheers,
> Stefan
|
|
|
| Re: SQL handling in CDO [message #615402 is a reply to message #111807] |
Tue, 05 February 2008 18:36 |
|
Hi Stefan,
You're pretty right and there's already https://bugs.eclipse.org/bugs/show_bug.cgi?id=214487 for this issue. I've even committed preparation work for it (see IDBStatement).
There have been 2 reasons for the StringBuilder design:
- Currently the DBStore can only work in auditing mode which means that rows are never updated (well mostly) but rather reinserted to preserve the old state. In non-auditing (and delta-support) mode the needed update statements would depend on the actual deltas. For a single table htere would be many different update statements possible. I simply was unsure about the overhead of creating so many prepared statements. This is why I spent effort for a small DML framework that abstracts away the concrete decision of whether to use prepared or unprepared statements.
- I was always a bit unsure how connection pools cope with vast numbers of prepared statements. There's already https://bugs.eclipse.org/bugs/show_bug.cgi?id=216586 with a little preparation work for this issue.
Comments or recommendations for these topics are greatly appreciated ;-)
Although these topics are not "dead" I decidied to postpone all work on the native DBStore in favour of developing the new HibernateStore together with Martin. This will be ineresting especially for you since you don't need the auditing mode (which I suspect will not be supported by the HibernateStore in a first run).
Cheers
/Eike
Stefan Winkler schrieb:
> Hi Eike,
>
> I created a patch to my bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=217255 which fixes the
> date issues in mysql.
> When I was debugging to find out where the objects and revisions are
> retrieved I found out that you store objects using the stringbuilder to
> create the complete SQL statement, but you use the JDBC
> ResultSet.getXxx() methods to retrieve values.
>
> Why is that? Storing the date using a JDBC Statement together with
> ?-Placeholders and set-methods like setTimestamp would have been easier
> and more error-proof than the stringbuilding thing (also it would make
> db-adapters smaller, as most of the appendValue-logic is already
> implemented in JDBC).
> The problem is also, that it is a bit unclear how the MySQL JDBC-driver
> handles timezones. So expect timezones not to work with my patch above ...
>
> I would open a bug for the stringbuilder <-> JDBC inconsistence, because
> I think this is a design problem. However, the changes would be rather
> large and I guess the Teneo-CDO-integration will replace the CDO
> relational mapping anyway, eventually eliminating potential issues.
>
> Cheers,
> Stefan
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.03330 seconds
] 
Search
Help
Register
Login
Home
