Hi,
Oliver Zeigermann wrote:
Carlos!
First of all I must say that I am very impressed by your work! Thanks again, Carlos! I am pretty sure many people will benefit from your contribution.
Anyway, I had a closer look at all this and now have some questions. Please take them as questions of someone who wants to understand and learn and not as any form of criticism:
Well, I'm not an OJB or database expert, just used it in a couple of projects.
Database Scheme ---------------------------
The OJB implementation uses the old Slide database scheme, right? Wouldn't this mean that we can use the (old) rdbms content store so that all data goes to the file system?
I followed basically the same schema but changed some types since OJB provides automatic translation for things like dates and boolean. So the schema it's not exactly the same and the old one will probably gives errors with OJB.
You can pair the OJB store with any other store I guess. I tested it with the txfile store.
Property Values -----------------------
I like the property value mechanism, but was wondering if there was an alternative mode to store properties in a way compatible to the old mechanism? This would be useful when migrating to the OBJ store having legacy data.
We can add store parameter to disable the extended functionality or to limit it to certain properties. The DefaultPropertyHandler just do the same as before and it's used for most properties except for the *-set ones.
I think, a better way is to write a real dump/restore tool that works at the webdav or Slide abstraction level. This way it's possible to migrate from one store type to another without loosing any relevant info, like history, permissions, properties, etc. In fact I'll be needing that at work so I guess I'll need to get to it someday.
Peer Classes -------------------
I have seen almost all people using some sort of DAOs with their ORM tool and I guess the peer classes are just for the same purpose. I am neither an OJB, nor an ORM expert so I was wondering why? Reading something like this
http://www.jpox.org/docs/jdo_2_0/jdo_transactions.html
at least JDO 2 will support a detach mechanism which would allow to let objects live longer than the transaction associated. This way it would be no problem to have the objects in global caches as well. Is this just impractical or does OJB simply not support this?
I'm not an expert either and only used OJB in a couple of simple projects. Currently, I'm using the PersistenceBroker level which is the lowest that OJB provides and the one I'm familiar with. I also thought that maybe we can get more performance at this level since we'll probably have more control. Yes, the peer classes are the POJO's of DAO and can be used as such if we move to the DAO level which OJB also supports. A more elegant solution will be to map directly the Slide objects like NodeRevisionDescriptor, etc. but that might be difficult because usually DAO and similar tools do have limitations on mapping complex objects and that's the reason I created the peers which I can simplify to fit the O/R tool. One limitation of working at the PersistenceBroker level, as you point out, is that transactions are database transactions not object transactions and that limit some uses. Again we can explore that and move to the DAO level if that provides more benefits. An additional benefit of working with DAO would be that we could replace OJB if we find a better implementation.
Sequence Store -----------------------
Maybe there is a misunderstand concerning the sequence store. A sequence is nothing Slide stores or uses as data, but pretty much a mapping to the sequence mechanism of the underlying database. It is much more comparable to the sequence concept provided OJB itself. If this is impossible to map it would be much safter to simply omit the sequence store as it really is optional.
Fine. I thought it was needed to generate unique numbers for the history stuff. The OJB sequence manager provides implementations for native database sequences but also a couple of generic ones like the one I implemented in the store using a table, so that it's portable across all databases. I tried to plug into the OJB sequence manager but found it not as straightforward since it's based on FieldDescritors not just sequenceNames so we'll have to provide a "fake" FieldDescriptor implementation to use it. But it may be possible to use OJB's.
Author Tags ------------------
The Slide community has voted to remove all author tags some time ago. Would you allow me to remove your author tags as well? This is not to take away the credit from you (you would still get it through the contributors page which is even more visible), but to transfer the responsibility to the community.
No problem, just saw author tags in one of the other stores, so I added them.
Thanks in advance,
Oliver
On Mon, 03 Jan 2005 00:54:00 +0900, Carlos Villegas <[EMAIL PROTECTED]> wrote:
Happy New Year,
As promised, I've submitted an initial implementation of a slide store based on Apache OJB O/R tool. I created a new bug report in bugzilla (Bug 32913) and attached the files. I've implemented all stores except the content store. Need more time to think about it. The BLOB type is not supported by all databases (though most have some support for large objects) and still need to check if OJB have some generic way of dealing with large binary objects. There is support for changing the table prefix via a build property. The SQL is generated from the peer classes directly using xdoclet and torque. However, torque doesn't do a good job generating the sql script and the create statements may need to be reordered manually so that tables that are target of referencial integrity constraints are created first. Need to check if commons-sql does a better job. Also I've implemented a mechanism to store property values that consists of lists like version-set or group-member-set in a separate table, one list item per row. I tested PostgreSQL 7.4.6/8.0.0rc2 and MySQL 4.1.8. Didn't run the full testsuite, just verified that it basically works by creating some folders and files and creating versions/checkout/checkin, etc. It's a first try, mostly followed the RDBMS logic and converted it to OJB. Need to optimize the mappings and tune OJB for Slide behaviour.
Oliver, please check it out and go ahead an make any adjustments. As I said I'll think about the BLOB issue but I won't have much time for this during the following 2 or 3 weeks.
Regards,
Carlos
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
