Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » SQL handling in CDO
SQL handling in CDO [message #111807] Tue, 05 February 2008 15:39 Go to next message
Stefan Winkler is currently offline Stefan WinklerFriend
Messages: 302
Registered: July 2009
Location: Germany
Senior Member
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 #111815 is a reply to message #111807] Tue, 05 February 2008 18:36 Go to previous message
Eclipse UserFriend
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 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6505
Registered: July 2009
Senior Member
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


Previous Topic:SQL handling in CDO
Next Topic:Hibernate-CDO
Goto Forum:
  


Current Time: Mon Sep 21 10:46:13 GMT 2020

Powered by FUDForum. Page generated in 0.01832 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top