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

Re: Status of the ozone project

On Tue, 19 Sep 2000, Martin Harper wrote:
> Falko Braeutigam wrote:
> 
> > On Thu, 14 Sep 2000, Martin Harper wrote:
> > > I do think a fully-fledged ODMG wrapper to Ozone would be good, if a lot of work -
> > > the current interface is great for internal stuff - between different modules of the
> > > same program - because you can do all the database work in a single
> > > implicitly-transactioned method call, set up precisely as it's needed, and optimised
> > > to do the work in the best way possible. Unsurprisingly, really, since that was what
> > > it was designed for...
> > >
> > > However, if you're writing middleware, and you have to provide access to parts of
> > > the database to external programs, then you're in trouble - you either have to make
> > > the types of access very limited, or you have to implement a proper query language,
> > > in which case you might as well pick OQL because it's the one everyone else uses.
> > Hmmm. I don't see the relation between ODMG and the use of ozone for writing
> > middleware. Can you explain more?
> 
> Well, it's like this...
> 
> The system I'm developing is a location system - the idea being that you can plug in any
> (possibly multiple) means of locating things, and everything will get sorted for you. You
> will be able to perform queries like "what can object 123 see?" and "what can be touched
> by object 123?". So far so good.
> 
> If you have more than one locator for each object, then you need a way of mapping locators
> to locatables, and it needs to be persistent. You also need a way of storing "artifical
> location information" - like the positions of rooms, and of pieces of equipment that don't
> have location technology on them, like printers, perhaps. Ozone handles all this very
> well.
> 
> Now, in practice there are lots of attributes things can have, and location is only one of
> them. So you might want to have a seperate database containing other information about
> object 123. Like - what is it, and, if it's a person, what job, name, pay, etc.
> 
> But this would make combined queries, like "what patients are there who are not within
> "treatment" range of a doctor?", complicated to perform. The application would have to
> decide the order of the query, whereas our system can perhaps decide that better (since it
> knows how many things are in close proximity to each patient/doctor).
> 
> So what would be desired would be for the application using our system to just define his
> DB objects in the usual manner, but make sure that the locatable ones all extend
> xxx.Locatable. And then it could store and access objects in the database in a normal,
> ODMG-compliant, manner - not worrying about our system at all until it needs to find out
> about locations.
> 
> Which would also mean that the OODB would also be effectively pluggable - and if someone
> already had an ODMG-compliant database that they were using, it might be possible to adapt
> our system to use their database...
> 
> Any of that make sense?

Sure. It just seemed that you need ODMG just to be able to explicitely demarc
transaction demarcation, which is possible with the native ozone API too.

Ok, you want the database to be pluggable. This makes sense, of course. And I
don't want to bother you all with to many theoretical aspects but I have to say
this again: objectbases are totally different from databases. The relational
algebra and SQL are strong and clear specs. Everyone can implement them and it
makes perfect sense to force database vendors to support those standards. The
picture is totally different for OODBMSs (or better objectbases). There is no
strong object model, object algebra or something. Every product supports
different object modells. IMO this makes up the actual power of OODBMSs - but
on the other hand makes it harder to keep the products compatible.

However, standards are good and pluggable databases are even better. Therefore
ozone provides a ODMG wrapper, which makes it easy to port applications that
are based on the ODMG model to and from ozone. Martin, are you aware of this?
If yes, what do you think is needed for a "fully-fledged ODMG wrapper"? OQL?

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