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