Re: [OJB-developers] OJB relationships & more

[Thomas M. <tho...@ho...>]

Hi Cristian,

Christian Sell wrote:
> 
> 
> I think, when a relationship is resolved, you will alost always end up
> accessing all the objects therein. Your argument about the "fourth element"
> is not convincing to me, as there is no notion of ordering in relationships.
> You would always have to iterate the relationship and decide based on the
> object state which one you need. And, if you only need a few particular
> objects from a relationship, you should use an explicit query in the first
> place. My point: when a relationship is resolved, the underlying semantics
> are that ALL objects are requested.
> 

Good argument. I added this as a feature request to the todo list.

> What I do see is that an iteration over a relationship could be dropped
> before the end is reached because some condition is met, e.g. because the
> user stops paging in the list she is presented with. This should be handled
> by a cursor-based relationship iterator, i.e. the iterator is internally
> based on a JDBC ResultSet (an SQL cursor), and objects are only instantiated
> when iterated over.
> 

That's a good idea. OJB already supports Iterators
(PersistenceBroker.getIteratorByQuery(...)). It's not difficult to write
lazy collections (based on such iterators) instead just exhausting the
Iterator to fill a Vector as it is done now in
PersistenceBroker.getCollectionByQuery(...).
I'll add this to the todo list. 

> > Class ID's are superfluous. Field ID's are necessary to provide a order
> > relation for the Comparator used for sorting.
> > There will be a complete review and cleanup of the existing DTD once we
> > have included all 1.0 features to the existing DTD (n:m relationships,
> > automatic foreignkey assignment, JNDI naming)
> 
> Looking at the respoistory, I also see some need for clean up. The things
> that immediately come to my mind were:
> 
> - make the structure XML-like. Currently, the repository syntax is a hybrid
> between XML and java properties files. As I see it, this is due to your
> parser, which only works on the first level (it does not use a stack
> internally). Therefore, you have introduced stuff like "<url.protocol>",
> where
> it should really be "<url><protocol></protocol></url>". I really think this
> should be changed asap. I could donate a SAX ContentHandler base class which
> makes this rather easy.
Ivan provided a clean design for a DTD. (I guess you'll find it in the
mailinglist archive. If not I can post it to you). When all features
required for release 1.0 are there I'm planning to have a rewrite of DTD
and Parser. Your help is of course welcome. 
> - introduce field-level ConversionStrategies. This is a must IMO.
> - introduce the "jndi-lookup" subelement for the JdbcConnectionDescriptor
> 
ALready on the todo list.

> > > Q4: ==================================
> > > Are there any plans to remove the need for separately mapping foreign
> key
> > > attributes? I find this a rather annoying requirement, which clearly
> defeats
> > > the notion of "transparence".
> > >
> >
> > I'm not sure if I understand you right?
> > Currently OJB requires to set foreign key attributes manually.
> > (E.G: we create a new A with 20 B objects in a collection attribute.
> > a.primary_key is computed automatically with the <autoincrement>
> > features. But we have to set the b.foreign_key attributes referencing to
> > a.primary_key manually.)
> > This is of course annoying and has to be replaced by some automatic
> > solution. This feature is already on the todo list. But I have not
> > started working on it.
> 
> Well, my point is going a bit further. I would even want to avoid the
> b.foreign_key attribute altogether, as it clearly is a database artifact
> that has no significance to the object model. After all, B already has a
> my_a attribute. If you want to persist a plain Java class which was not
> designed with OJB in mind (which is what transparence is about), it will
> most certainly not have the b.foreign_key attribute. I am sure this can be
> done rather easily, as the value is there in the target objects PK, and can
> be retreived through metadata during storage operations (done this before).
> 

OJB started as a MAPPING tool. That is we assumed that there is a full
database model. The Developers I talked to had no objections against
having primary key attributes and foreign key atributes in the
persistent classes. Obviously those things don't belong to the domain
model. but they they can be clearly marked as not being part of the
domain model (e.g. by declaring them as "private transient"). As most OO
designs don't allow direct access to attributes but only through getters
and setters these "technical" attributes can completely hidden from the
application developer.
Thus I decided to consider this kind of transparency as "nice to have"
but not essential.
Regarding your idea to eliminate the need of foreign key attributes I
agree that this should be possible without to much effort.

> > Any help is appreciated a lot!
> 
> I am currently making up my mind with respect to an object persistence
> solution for my projects. TopLink is not an option for obvious reasons, and

TopLink is really crowded with an immense mass of really good features.
Also the mapping Workbench is really great. But it's so expensive.
In my company we have developed an abstraction layer that encapsulates
persistence layers to let projects decide whether they want to use
TopLink or OJB. It's only a configuration entry to be changed...

> EJB 2.0 is giving me a headache with all those interfaces and helper classes
> you need to make it work, and the lack of O/R features like inheritance &
> polymorphism.

I agree! THAT is poor design (not my harmless foreign key attributes ;-)

 I also owe a lot to the OSS community, so it would be about
> time to make a contribution myself. 

That's great.

> As I would plan to use OJB in
> production, one of my main requirements would be to remove all the
> performance-critical issues like singular loading, and all other excess DBMS
> calls (like those someone else mentioned about DLists, which allocate
> sequence values for themselves and all elements - yuck).

OK DLists must work this way. With a better SequenceManager (as it comes
with the next release) they won't be a big Problem.

What may become a performance bottle neck is the LockManager. Currently
it's based on a DB table. That is all locking, unlocking, checking for
locks etc. produces database traffic.
For heavy duty apps a separate LockManager server is a must. For the
singlevm mode a inmemory Lockmanager would be sufficient.



> Second would be the
> removal of non-transparency, 

> and a JDO interface is also quite important.

The next release will be called 0.7. It will provide a completed client
server architecture (now also the MetaData Layer will be accessed
remotely). With this release there will be a solid persistence kernel
working that could be used for a JDO Implementation.
I see 2 possible approaches for the JDO implementation:
1. start coding and make as much "copy paste"-reuse from the ODMG
implementation.
2. Start with a refactoring:
  - Extract everything from the ODMG implementation that might be useful
for JDO too. 
    Build a generic Object Transaction Kernel based on this refactoring.
  - Reimplement ODMG based on this new Kernel,
  - Implement JDO based on the new Kernel.

This would be a layered architecture with
- OJB PersistenceBroker as base
- OJB Object Transaction Kernel (OTK) (based on the Broker)
- ODMG and JDO Implementation build on top of the OTK.

This is obviously the best way to go but will be a lot of work too...

> Some of this would possibly require a redesign/reworking of the kernel. If
> we could come to an agreement (possibly after more discussion), I may be
> willing to make a significant time investment in the near future (towards
> end of the year). What do you think?
> 

Sounds great. Of course will need some more clarifications on details.
But as mentioned before: I'm really glad to get support!


cheers,

Thomas

> regards,
> Christian