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