[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Evaluation

On Fri, 16 Mar 2001, Torsten Rüger wrote:
> IHello,
> I have evaluated Ozone-DB for a couple of days now and just want to tell 
> you what I think, in the hope it will be useful for you to improve your 
> system. 

I'm sure it will. Thanks for your comments!

> Specifically, I want to develop a web application using an oodb 
> and webmacro. I have previously done this using Objectivity and it 
> worked _very_ well. Now I am looking for a free alternative, because 
> Objectivity is rather expensive and there is no client to bill.
> 
> So first of all let me concratulate you for having built such a hughe 
> system, which seems function well in it's intended way. I have run 
> several of the examples and all seems ok.
> 
> I have choosen not to use it and here is why:
> -- the architecture is the wrong way around. In ozone the client is dumb 
> (only the data is carried in the proxies) and the server carries the 
> full Object implementation. So I must place my code in the server to be 
> efficient, but I need the result at the client. The better way is to let 
> the server just store data, and have the client do data manipulation.

If the ozone architecture is overall wrong, then the EJB architecture is
wrong too. Which would mean that 10000s of programmers currently are going in
the wrong direction ;)

There are advantages and disadvantages, sure. For example the Objectivity
approach produces bad performance when several client are working (and
changing) one object. In this case, the entire object is again and again send
around in the network to each client. So, I believe that neither way is just
"wrong". 

> 
> -- the equation one funtion, one transaction is often not true. 
> Especially with the code being on the server, I'd have to collect my 
> data, keep it dumb (in basic types) send it to the server and do the 
> work there. For me a transaction is more often a change in attribute 
> here, an object added there and so on, two or three things together 
> anyway. I loose the "atomic" if I do that on the client.

ozone support explicit transaction demarcation in the client code...

> 
> -- Schema evolution is missing (I haven't seen any mention). This is not 
> acceptable, because any real world application _will_ change. In fact 
> quite advanced tools would be of benefit here, i.e. Adding/removing data 
> fields is simple, changing container types automatically would be nice. 
> (One of the constant choices one has to make in a oodb is the 
> implementation of an association. Invariably these have to change)

I agree, schema evolution in ozone is a problem. But just adding new
members and changing relations between objects is possible and relativly easy
to program in ozone.

> 
> --Also the architecture makes schema evolution impossible, because one 
> JVM can only have one instance of a class loaded.
You are wrong here. Using ClassLoaders it is no problem to run different
version of one class in different threads. (see servlet engines and EJB
containers)

> -- Search facilities are essentaial. When they are not in the db, it 
> just means the programmer has to code them (always the same, rebuild the 
> wheel). Also it leads to better performace.

Hmmm... but programmers do this all the time. Choosing a collection type
putting objects in and getting them back for a key or index or whatever. If
this is no problem for "ordinary" Java code why then is it a problem for
"persistent" code?

> 
> Please don't take this wrong, it is meant to be constructive.
> I would really like to see an open all java oodb, but am not in a 
> position to help you other than this.

No problem. Again, many thanks for your comments.


Falko
-- 
______________________________________________________________________
Falko Braeutigam                              mailto:falko@smb-tec.com
SMB GmbH                                        http://www.smb-tec.com