springframework-developer

[Springframework-developer] JdoDialect and detach?

[Marc L. <ma...@lo...>]

Hi,

forget something in my last email a few minutes ago. JdoDialect only 
handles vendor differences regarding JdbcConnection obtaining, it would 
be nice to have the same for attach/detach APIs. This is of course 
non-existant when we all have JDO2, but the same goes for the JDBC 
connection issue.

Or is this allready handled somewhere else? Have not found something yet.


-- 
regards
Marc Logemann
[blog] http://www.logemann.org
[busn] http://www.logentis.de

Re: [Springframework-developer] JdoDialect and detach?

[Juergen H. <ju...@in...>]

We did consider supporting attach/detach hooks as well, but decided not to
do so, because the exact syntax and behavior of those operations weren't
clear back then. In contrast to that, almost all JDO 1.0 implementations had
JDBC Connection exposure and flushing for ages.

At this point of time, our plan is to not extend JdoDialect any further,
because JDO 2.0 is just around the corner. Our JdoTemplate and
DefaultJdoDialect already support the standard JDO 2.0 API, so once you get
a JDO impl that supports JDO 2.0, that's gonna be immediately available to
you.

For JDO 2.0 previews such as current Kodo versions, you can always implement
a JdoCallback and cast the passed-in PersistenceManager to the
vendor-specific PM interface, calling attach/detach and other JDO 2.0
preview operations there. This can of course be replaced with straight
JdoTemplate calls once the particular JDO impl officially supports the
standard JDO 2.0 API.

As a side note: The pluggable JDBC Connection exposure in JdoDialect can
still be valuable even with JDO 2.0. For example, you might want to expose
the native JDBC Connection to JDBC data access code, which could be casted
to OracleConnection or the like. In this case, you still need
vendor-specific extraction calls, because standard JDO 2.0 always exposes a
wrapped handle...

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Marc Logemann
Sent: Thursday, June 16, 2005 10:56 PM
To: spr...@li...
Subject: [Springframework-developer] JdoDialect and detach?


Hi,

forget something in my last email a few minutes ago. JdoDialect only
handles vendor differences regarding JdbcConnection obtaining, it would
be nice to have the same for attach/detach APIs. This is of course
non-existant when we all have JDO2, but the same goes for the JDBC
connection issue.

Or is this allready handled somewhere else? Have not found something yet.


--
regards
Marc Logemann
[blog] http://www.logemann.org
[busn] http://www.logentis.de



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] JdoDialect and detach?

[Marc L. <ma...@lo...>]

Juergen Hoeller wrote:
> We did consider supporting attach/detach hooks as well, but decided not to
> do so, because the exact syntax and behavior of those operations weren't
> clear back then. In contrast to that, almost all JDO 1.0 implementations had
> JDBC Connection exposure and flushing for ages.

I thought that the syntax differences would be the initial motivation to 
write JdoDialect. But i can think of very different approaches of 
detach/attach back then.

> At this point of time, our plan is to not extend JdoDialect any further,
> because JDO 2.0 is just around the corner. Our JdoTemplate and
> DefaultJdoDialect already support the standard JDO 2.0 API, so once you get
> a JDO impl that supports JDO 2.0, that's gonna be immediately available to
> you.

Of course, this is also my thinking, however right now we are in a sad 
situation which i will exaplain below. Right now it would be very nice 
to have a JdoDialect handling this too, then JdoTemplate could use this 
dialect and we would be able to abstract away the differences between 
current detach/attach approaches between vendors. But i agree that this 
would only be a short-time benefit.

> For JDO 2.0 previews such as current Kodo versions, you can always implement
> a JdoCallback and cast the passed-in PersistenceManager to the
> vendor-specific PM interface, calling attach/detach and other JDO 2.0
> preview operations there. This can of course be replaced with straight
> JdoTemplate calls once the particular JDO impl officially supports the
> standard JDO 2.0 API.

Yeah i saw that JdoTemplate allready provides JDO2 public draft style 
attach/detach API (i heard that the JCP-EG might want to change the 
detach API naming for the final spec) but right now i, as a kodo user, 
cant use the convenience methods, because kodo detach API is different 
to the public draft. They said that they wont change to the public JDO2 
draft API spec, because chances are high that it will change ;-)

Of course, implementing an own Callback is possible, you can also create 
a child of JdoTemplate and override the attach/detach methods in there.

All in all its an unhealthy situation in the JDO area, we still dont 
have JDO2 and it seems this will take a while and we have different 
vendors supporting different parts of JDO2, this mixed with unstable 
public draft seems not the ideal situation. All in there we have spring 
trying to cope with that situation ;-)

> 
> As a side note: The pluggable JDBC Connection exposure in JdoDialect can
> still be valuable even with JDO 2.0. For example, you might want to expose
> the native JDBC Connection to JDBC data access code, which could be casted
> to OracleConnection or the like. In this case, you still need
> vendor-specific extraction calls, because standard JDO 2.0 always exposes a
> wrapped handle...

Hmm, yeah you get a handle which you can ask for a java.sql.Connection 
(ok its Object in reality but most implementations will return a JDBC 
connection) in the method getNativeConnection(). There is not much of a 
difference between a properietary vendor call for a JDBC connection and 
the JDO2 one, except for some connection methods which will throw an 
exception like getMetaData() or rollback(). But perhaps i am missing 
something.


-- 
regards
Marc Logemann
[blog] http://www.logemann.org
[busn] http://www.logentis.de

Re: [Springframework-developer] JdoDialect and detach?

[Juergen H. <ju...@in...>]

If there is enough interest, we can still add attach/detach hooks to our
JdoDialect abstraction. This would particularly make sense if standard JDO
2.0 implementations are still a while away.

The current JDO 2.0 API methods specify a "makeTransactional" argument for
"attachCopy", where we currently always pass in "true", and no-arg
"detachCopy" methods. The final JDO 2.0 API might specify no-arg
"attachCopy" versions and "detachCopy" versions with a fetch plan argument
(which can be null) instead.

So one option would be to continue covering plain "attachCopy"/"detachCopy"
without special arguments, for both single objects and Collections, in our
JdoTemplate. Such default no-arg methods certainly make sense in general,
even if we might add JDO2-specific overloaded versions (for example with
explicit fetch plan argument) in the future.

To make the actual behavior pluggable, we could factor the actual
invocations out to corresponding new JdoDialect methods, by default calling
the standard JDO 2.0 methods accordingly. This could then be overridden for
special vendor-specific attach/detach methods, whether current JDO 2.0
previews or overloaded vendor-specific versions alongside the standard JDO
2.0 methods.

Kodo currently has no-arg "attach" and "detach" methods. Versant Open Access
currently has "versantAttachCopy" with one or two boolean args, and
"versantDetachCopy" with a String arg (the fetch group; can be null). Both
could quite easily be used within a Kodo/Versant-specific JdoDialect,
passing in default arguments where necessary.

I'm certainly open to go down that route; I'm just a little undecided
whether it makes sense to do it at this point of time. I'm currently in the
process of gathering some further opinions. If it turns out that the general
agreement is in favor of such hooks, I'll add them for Spring 1.2.2
(scheduled for coming Thursday/Friday).

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Marc Logemann
Sent: Friday, June 17, 2005 12:29 PM
To: spr...@li...
Subject: Re: [Springframework-developer] JdoDialect and detach?


Juergen Hoeller wrote:
> We did consider supporting attach/detach hooks as well, but decided not to
> do so, because the exact syntax and behavior of those operations weren't
> clear back then. In contrast to that, almost all JDO 1.0 implementations
had
> JDBC Connection exposure and flushing for ages.

I thought that the syntax differences would be the initial motivation to
write JdoDialect. But i can think of very different approaches of
detach/attach back then.

> At this point of time, our plan is to not extend JdoDialect any further,
> because JDO 2.0 is just around the corner. Our JdoTemplate and
> DefaultJdoDialect already support the standard JDO 2.0 API, so once you
get
> a JDO impl that supports JDO 2.0, that's gonna be immediately available to
> you.

Of course, this is also my thinking, however right now we are in a sad
situation which i will exaplain below. Right now it would be very nice
to have a JdoDialect handling this too, then JdoTemplate could use this
dialect and we would be able to abstract away the differences between
current detach/attach approaches between vendors. But i agree that this
would only be a short-time benefit.

> For JDO 2.0 previews such as current Kodo versions, you can always
implement
> a JdoCallback and cast the passed-in PersistenceManager to the
> vendor-specific PM interface, calling attach/detach and other JDO 2.0
> preview operations there. This can of course be replaced with straight
> JdoTemplate calls once the particular JDO impl officially supports the
> standard JDO 2.0 API.

Yeah i saw that JdoTemplate allready provides JDO2 public draft style
attach/detach API (i heard that the JCP-EG might want to change the
detach API naming for the final spec) but right now i, as a kodo user,
cant use the convenience methods, because kodo detach API is different
to the public draft. They said that they wont change to the public JDO2
draft API spec, because chances are high that it will change ;-)

Of course, implementing an own Callback is possible, you can also create
a child of JdoTemplate and override the attach/detach methods in there.

All in all its an unhealthy situation in the JDO area, we still dont
have JDO2 and it seems this will take a while and we have different
vendors supporting different parts of JDO2, this mixed with unstable
public draft seems not the ideal situation. All in there we have spring
trying to cope with that situation ;-)

>
> As a side note: The pluggable JDBC Connection exposure in JdoDialect can
> still be valuable even with JDO 2.0. For example, you might want to expose
> the native JDBC Connection to JDBC data access code, which could be casted
> to OracleConnection or the like. In this case, you still need
> vendor-specific extraction calls, because standard JDO 2.0 always exposes
a
> wrapped handle...

Hmm, yeah you get a handle which you can ask for a java.sql.Connection
(ok its Object in reality but most implementations will return a JDBC
connection) in the method getNativeConnection(). There is not much of a
difference between a properietary vendor call for a JDBC connection and
the JDO2 one, except for some connection methods which will throw an
exception like getMetaData() or rollback(). But perhaps i am missing
something.


--
regards
Marc Logemann
[blog] http://www.logemann.org
[busn] http://www.logentis.de


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] JdoDialect and detach?

[Marc L. <ma...@lo...>]

Juergen Hoeller wrote:

> To make the actual behavior pluggable, we could factor the actual
> invocations out to corresponding new JdoDialect methods, by default calling
> the standard JDO 2.0 methods accordingly. This could then be overridden for
> special vendor-specific attach/detach methods, whether current JDO 2.0
> previews or overloaded vendor-specific versions alongside the standard JDO
> 2.0 methods.

+1, thats the approach i had in mind in the last days.

> Kodo currently has no-arg "attach" and "detach" methods. Versant Open Access
> currently has "versantAttachCopy" with one or two boolean args, and
> "versantDetachCopy" with a String arg (the fetch group; can be null). Both
> could quite easily be used within a Kodo/Versant-specific JdoDialect,
> passing in default arguments where necessary.

And i know at least one more vendor which could be easily adjusted to 
that as well.

> I'm certainly open to go down that route; I'm just a little undecided
> whether it makes sense to do it at this point of time. I'm currently in the
> process of gathering some further opinions. If it turns out that the general
> agreement is in favor of such hooks, I'll add them for Spring 1.2.2
> (scheduled for coming Thursday/Friday).

Yeah and here we will certainly have different oppinions. Most people 
will think "hey JDO2 is nearly out the door - no need for dialect stuff 
anymore". I can agree on this only to that point that this argument is 
true and i dont believe this. I asked Patrick Linskey (or Abe White, 
dont know anymore) from Solarmetric and he said that JDO2 is not THAT near.

Anyway, i am interessted to hear other oppinions on that issue. Perhaps 
i will ask the Solarmetric guys about that to get some more arguments. 
Really funny was a statement from Patrick to me where he believed that 
there is allready an attach/detach abstraction inside JdoDialect, so it 
seems he likes the idea so much that he thought its allready in there ;-)


-- 
regards
Marc Logemann
[blog] http://www.logemann.org
[busn] http://www.logentis.de

Re: [Springframework-developer] JdoDialect and detach?

[Juergen H. <ju...@in...>]

Marc,

I'm actually in regular contact with Patrick myself; we usually keep each
other up-to-date on Spring/JDO things. Regarding attach/detach in
JdoDialect, there's probably some miscommunication there ;-) Patrick and I
have been talking about the need for this before, but no such thing has made
it into the Spring codebase yet.

Anyway, I'm leaning towards adding those methods in the meantime. Even when
JDO2 is final and mainstream, there might still be some reasons to override
the default attach/detach behavior in a vendor-specific fashion, for example
customizing the default fetch group or calling some vendor-specific
overloaded version of attach/detach. Alternatively, there's always the
option to implement custom JdoCallbacks based on vendor-specific PM API, of
course.

I've already refactored JdoTemplate and DefaultJdoDialect accordingly, but
not committed the changes yet. In the course of this, I've also added a
"newNamedQuery" hook to JdoDialect, factoring out named query creation too
(intended for pre-JDO2 named query support as found in Kodo, Lido, Versant
Open Access). In total, this should pretty much cover most functionality
that current JDO impls offer beyond JDO 1.0.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Marc Logemann
Sent: Sunday, June 19, 2005 4:29 PM
To: spr...@li...
Subject: Re: [Springframework-developer] JdoDialect and detach?


Juergen Hoeller wrote:

> To make the actual behavior pluggable, we could factor the actual
> invocations out to corresponding new JdoDialect methods, by default
calling
> the standard JDO 2.0 methods accordingly. This could then be overridden
for
> special vendor-specific attach/detach methods, whether current JDO 2.0
> previews or overloaded vendor-specific versions alongside the standard JDO
> 2.0 methods.

+1, thats the approach i had in mind in the last days.

> Kodo currently has no-arg "attach" and "detach" methods. Versant Open
Access
> currently has "versantAttachCopy" with one or two boolean args, and
> "versantDetachCopy" with a String arg (the fetch group; can be null). Both
> could quite easily be used within a Kodo/Versant-specific JdoDialect,
> passing in default arguments where necessary.

And i know at least one more vendor which could be easily adjusted to
that as well.

> I'm certainly open to go down that route; I'm just a little undecided
> whether it makes sense to do it at this point of time. I'm currently in
the
> process of gathering some further opinions. If it turns out that the
general
> agreement is in favor of such hooks, I'll add them for Spring 1.2.2
> (scheduled for coming Thursday/Friday).

Yeah and here we will certainly have different oppinions. Most people
will think "hey JDO2 is nearly out the door - no need for dialect stuff
anymore". I can agree on this only to that point that this argument is
true and i dont believe this. I asked Patrick Linskey (or Abe White,
dont know anymore) from Solarmetric and he said that JDO2 is not THAT near.

Anyway, i am interessted to hear other oppinions on that issue. Perhaps
i will ask the Solarmetric guys about that to get some more arguments.
Really funny was a statement from Patrick to me where he believed that
there is allready an attach/detach abstraction inside JdoDialect, so it
seems he likes the idea so much that he thought its allready in there ;-)


--
regards
Marc Logemann
[blog] http://www.logemann.org
[busn] http://www.logentis.de


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] JdoDialect and detach?

[Marc L. <ma...@lo...>]

Juergen,

nice to hear that there is an ongoing communication between you and JDO 
vendors like Solarmetric. In fact Solarmetric seems quite positive 
regarding Spring to the level that they dont complain when i send them 
stacktraces with embedded Spring JDO classes in it. <g>

Like i said, i think it would be a great enhancement when Spring can 
help JDO developers by enhancing JdoDialect. In the future there will 
allways be a need for JdoDialect, because there is allways a gap between 
vendor impl's and spec. Thats where the competitions is really showing 
up. (i leave out the post JDO2 spec question at this time)

And yes, JdoCallbacks is allways an option, but if you get accustomed to 
use JDOTemplate and its convenience methods out of the box, you really 
want to leave that only for some rare cases and detach isnt rare at all 
inside my app. Call me lazy but thats the way it is ;-)

Great work.


Juergen Hoeller wrote:
> Marc,
> 
> I'm actually in regular contact with Patrick myself; we usually keep each
> other up-to-date on Spring/JDO things. Regarding attach/detach in
> JdoDialect, there's probably some miscommunication there ;-) Patrick and I
> have been talking about the need for this before, but no such thing has made
> it into the Spring codebase yet.
> 
> Anyway, I'm leaning towards adding those methods in the meantime. Even when
> JDO2 is final and mainstream, there might still be some reasons to override
> the default attach/detach behavior in a vendor-specific fashion, for example
> customizing the default fetch group or calling some vendor-specific
> overloaded version of attach/detach. Alternatively, there's always the
> option to implement custom JdoCallbacks based on vendor-specific PM API, of
> course.
> 
> I've already refactored JdoTemplate and DefaultJdoDialect accordingly, but
> not committed the changes yet. In the course of this, I've also added a
> "newNamedQuery" hook to JdoDialect, factoring out named query creation too
> (intended for pre-JDO2 named query support as found in Kodo, Lido, Versant
> Open Access). In total, this should pretty much cover most functionality
> that current JDO impls offer beyond JDO 1.0.
> 
> Juergen
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Marc Logemann
> Sent: Sunday, June 19, 2005 4:29 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] JdoDialect and detach?
> 
> Yeah and here we will certainly have different oppinions. Most people
> will think "hey JDO2 is nearly out the door - no need for dialect stuff
> anymore". I can agree on this only to that point that this argument is
> true and i dont believe this. I asked Patrick Linskey (or Abe White,
> dont know anymore) from Solarmetric and he said that JDO2 is not THAT near.
> 
> Anyway, i am interessted to hear other oppinions on that issue. Perhaps
> i will ask the Solarmetric guys about that to get some more arguments.
> Really funny was a statement from Patrick to me where he believed that
> there is allready an attach/detach abstraction inside JdoDialect, so it
> seems he likes the idea so much that he thought its allready in there ;-)


-- 
regards
Marc Logemann
[blog] http://www.logemann.org
[busn] http://www.logentis.de

Re: [Springframework-developer] JdoDialect and detach?

[Juergen H. <ju...@in...>]

OK, I'll commit the changes as I guess they are useful in any case. I agree
that we have to expect further operations to be added to JdoDialect, in
particular for post-JDO2 functionality that vendors will introduce. It
doesn't hurt to keep the existing hooks anyway, even in a JDO2 world, as
they introduce a nice level of customizability (through delegation rather
than through subclassing).

Existing JdoDialect implementations shouldn't be affected, as it's just a
bunch of new methods for JDO2-style functionality. If they implement
JdoDialect directly, they will have to implement those new methods once they
upgrade the Spring version that they compile against (which should be fine).
And most of them derive from DefaultJdoDialect anyway, which automatically
makes them inherit the default impls of those new methods.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Marc Logemann
Sent: Sunday, June 19, 2005 5:30 PM
To: spr...@li...
Subject: Re: [Springframework-developer] JdoDialect and detach?


Juergen,

nice to hear that there is an ongoing communication between you and JDO
vendors like Solarmetric. In fact Solarmetric seems quite positive
regarding Spring to the level that they dont complain when i send them
stacktraces with embedded Spring JDO classes in it. <g>

Like i said, i think it would be a great enhancement when Spring can
help JDO developers by enhancing JdoDialect. In the future there will
allways be a need for JdoDialect, because there is allways a gap between
vendor impl's and spec. Thats where the competitions is really showing
up. (i leave out the post JDO2 spec question at this time)

And yes, JdoCallbacks is allways an option, but if you get accustomed to
use JDOTemplate and its convenience methods out of the box, you really
want to leave that only for some rare cases and detach isnt rare at all
inside my app. Call me lazy but thats the way it is ;-)

Great work.


Juergen Hoeller wrote:
> Marc,
>
> I'm actually in regular contact with Patrick myself; we usually keep each
> other up-to-date on Spring/JDO things. Regarding attach/detach in
> JdoDialect, there's probably some miscommunication there ;-) Patrick and I
> have been talking about the need for this before, but no such thing has
made
> it into the Spring codebase yet.
>
> Anyway, I'm leaning towards adding those methods in the meantime. Even
when
> JDO2 is final and mainstream, there might still be some reasons to
override
> the default attach/detach behavior in a vendor-specific fashion, for
example
> customizing the default fetch group or calling some vendor-specific
> overloaded version of attach/detach. Alternatively, there's always the
> option to implement custom JdoCallbacks based on vendor-specific PM API,
of
> course.
>
> I've already refactored JdoTemplate and DefaultJdoDialect accordingly, but
> not committed the changes yet. In the course of this, I've also added a
> "newNamedQuery" hook to JdoDialect, factoring out named query creation too
> (intended for pre-JDO2 named query support as found in Kodo, Lido, Versant
> Open Access). In total, this should pretty much cover most functionality
> that current JDO impls offer beyond JDO 1.0.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Marc Logemann
> Sent: Sunday, June 19, 2005 4:29 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] JdoDialect and detach?
>
> Yeah and here we will certainly have different oppinions. Most people
> will think "hey JDO2 is nearly out the door - no need for dialect stuff
> anymore". I can agree on this only to that point that this argument is
> true and i dont believe this. I asked Patrick Linskey (or Abe White,
> dont know anymore) from Solarmetric and he said that JDO2 is not THAT
near.
>
> Anyway, i am interessted to hear other oppinions on that issue. Perhaps
> i will ask the Solarmetric guys about that to get some more arguments.
> Really funny was a statement from Patrick to me where he believed that
> there is allready an attach/detach abstraction inside JdoDialect, so it
> seems he likes the idea so much that he thought its allready in there ;-)


--
regards
Marc Logemann
[blog] http://www.logemann.org
[busn] http://www.logentis.de


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer