Re: Ozone based framework

Hi Gerd and Christian,

Thank you for your reply and sorry for the delayed answer, I had a busy
week.

I didn't want to write a client side caching mechanism for ozone, since
almost all the other object databases have it, and osone's philosophy of
database object handling is different. When I started to write this
extension I had two goals.

1. Provide some sort of basic indexing for ozone objects. These indices
should be native ozone objects, as indices in most relational databases
are special relational tables.

2. Somehow send detached, serialized ozone objects to the client side,
same way we can do it with hibernate. Detach an object, send it to the
client side for user display. If a client program changes a few objects
it can send them back for save. But this is not a client cache, since if
one object changes in the database, the client will not know about it.

These two functions are working now, but need a lot of testing. When
we're coding database objects, we can model them with simple POJO
objects with a few convention (they have to extend a database object
ancestor, and should use naming convention: xxxx_POJO). An ant script
then generates all the necessary ozone objects from them (xxxx_OZONE).
The objects can have complex methods as well, not just simple properties
and variables.

Server side application modules (servlets, EJB objects etc.) can still
use the native _OZONE objects, having all the advantages of ozone's
architecture, with the addition of the indexing mechanism. When we want
to send data to the client side we can still decide if we want to send
the objects the traditional ozone way (sending the RMI proxies) or we
can send the whole object graph as detached simple serializable POJO
objects. I've drawn a little diagram about the logical architecture
(please see the attached picture). This is not client side caching (it
doesn't know about parallel database updates nor server side
transactions) or if we want to see it as client side caching it's a
really primitive one. You can see it this way: xxxx_OZONE objects are
using server side transactions and will see server side modifications
immediately, where xxxx_POJO objects are only copies (snapshots) from
the live database, but they can be saved back to the current database.

Christian: I've seen your site at oomega, your software looks very
promising to me. I sure will play with it for a little, but I'd like to
ask a question. Does a complex generated database model can work well
with hibernate's (or any other) relational mapping? I have concerns
about it.

Regards:
Gejzir



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ozone-users mailing list
Ozone-users@...
https://lists.sourceforge.net/lists/listinfo/ozone-users