db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Topping <topp...@codehaus.org>
Subject Re: Apache JDO 2.0
Date Thu, 14 Apr 2005 14:35:25 GMT
Hi Craig,

Craig Russell wrote:

> Hi Brian,
> On Apr 6, 2005, at 10:52 PM, Brian Topping wrote:
>> Craig Russell wrote:
>> J5 is the reason I was bringing this up really.  We know that they 
>> are going to keep moving forward with support for future JDK 
>> classfile formats, and with different features as well.  I haven't 
>> gotten too deep with the enhancer code yet, but know a few things 
>> about the two bytecode libraries (was ready to get into it for my MOF 
>> project).  ASM is good if you just want to generate bytecode but want 
>> something that is a little higher level than pushing bytes out to a 
>> ByteArrayStream.  OTOH, CGLib is much more OO, but since it uses ASM, 
>> the two can be used together if you don't mind coding with compatible 
>> semantics to CGLib.  From the very cursory look at the output of 
>> other enhancers, I believe CGLib can probably to everything we need 
>> in about 20% of the time, and we could go back and hand-optimize what 
>> constructions we don't like after getting some experience with the code.
> I agree that the motivator here is J5. We *must* upgrade the enhancer 
> to work with that platform. I think the work needs to be done first in 
> ri11 and then migrated to JDO 2 project where we need to add features.
> I've discussed our options with the author of the ri11 enhancer and 
> will try to document our discussion, but you can appreciate it's a bit 
> tough not least because the author isn't officially working on our 
> project.

I'd like to take this work on, but need to segue it with 1)  the 
existing work that I am signed up for on the XML Schema stuff (which 
will take very little time and just needs to close out the questions 
that I had on it) and 2) whether the results are going to be usable from 
a project that I am currently developing.  I'll probably regret saying 
this, but I don't think it's that difficult a problem with CGLib, it 
just remains to be seen whether the problem and solution domains overlap 

>> FWIW, use of TQL doesn't really provide integration with Geronimo, it 
>> only means that we would be sharing code (as a shared library when 
>> used together).  It makes a lot of sense because both projects can 
>> leverage each other's work on query tokenization and transformation.  
>> The great thing about TQL is we can substantially increase the number 
>> of databases we support out of the box, although it doesn't provide 
>> any kind of query executive or optimizer, so it would not replace the 
>> manner by which the b-tree code is currently used for file storage.  
>> (But as you can imagine, the b-tree code would need to be refactored 
>> or mated with a TQL transform to be modularly used.)  As Gianny 
>> pointed out, it makes a lot of sense to use it, and it is easy to use 
>> once you are moving with it.
> Yeah, I didn't clearly communicate my understanding of the 
> relationship between TQL, JDO, and Geronimo.
> I have to say, though, that I would not reuse the query tree 
> walk/evaluator or the fostore b-tree implementation with TQL. Instead, 
> I'd implement a different tree walker to generate SQL trees and 
> implement a completely different StoreManager to talk SQL to a back 
> end. That's where I'd use TQL.

Hmm, I hadn't ever considered why this would be advantageous.  Could you 
elaborate?  From my perspective, using the existing TQL AST code gives 
us query compatibility with more databases as they are supported by TQL, 
something we have to write ourselves if we don't use their code.

> I'd like to use TQL not least in order to share the cache of objects 
> between CMP, EJB3, and JDO. To the extent possible, I'd like to allow 
> users to choose among these technologies for each piece of an 
> application instead of choosing at a very high level. So adding some 
> EJB3 entities to an existing CMP application should not be impossible. 
> Likewise, enhancing an EJB3 application to use some JDO should be easy.

Last I looked, TQL was not architected with personalities as loadable 
libraries.  But it strikes me that these personalities could be made 
into IoC components themselves, thus enabling the functionality you 
speak of.  This would be the first time this has been done though.  Is 
it something that is a high priority for the implementation?  I would 
vote for this as a 2.1 or 3.0.

>> Yes, but my reference was just in the context of JDORI, we do have 
>> permission to use that code when it fits our needs, correct?  
>> Regarding other projects, it's a very different story.  Apologies if 
>> I gave you a shudder with the wrong impression on using code from 
>> other projects.
> We are free to exploit everything in the xxx11 projects to use in our 
> yyy20 projects. I've actually been thinking about splitting out the 
> ri11 into several yyy20 projects: enhancer, query, runtime, model, a 
> few others. I don't think that ri11 is granular enough to e.g. add TQL 
> as the back end, or use a mapping model from other open source 
> implementations.

That being said, is it worth adding J5 enhancement capability to ri11 
first?  I would assert that CGLib is the way to go here, and if so, we 
are fundamentally changing the way we enhance and it would be better to 
include this as a part of a rewrite, not mash it into existing code and 
port it.

This leaves me wanting to get the 2.0 project started this week if 
possible.  What am I missing?


View raw message