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

Re: on objectOfClass method and listing of Db contents

Falko Braeutigam wrote:

> On Fri, 16 Mar 2001, Charilaos Pasantonopoulos wrote:
> > I read the discussions on the objectsOfClass method and how to list the
> > Db contents and it
> > seems to me that most people ( maybe because of relational Dbs ) expect
> > the Db to have such a way of
> > listing the contents.
>
> This exactly is the problem - people expect relational features when they
> just read "database". Therefore, even if this may cause other problems, I
> propose to start to call ozone "Object Server". If we all agree on this term I
> will change web site.
>
> > Falco wrote:
> > > it is possible to develop such an ad-hoc browsing tool because
> > > the structure of the database classes can be retrieved via Java
> > > reflection.
> >
> > Can we have a bit more on that ?
> > Introspect what to get what ? How do I get the first object to start
> > with ?
>
> The API does not provide ways to get "all object of a class" or all named
> (root) objects or something like this, to prevent bad (slow) application
> designs. Therefore I would not add those features to the user API.
>
> However, there are ways to add whatever features are needed for a browsing tool
> to the admin interface. I did the admin interface exactly to support things
> like an ad-hoc browsing tool. See org.ozoneDB.core.admin.*
>
> >
> > > But currently I do not know if such a tool is really needed.
> > > Because it would only be able to _show_ the object structure of the
> > > database.
> >
> > I need to get the Db filled with objects unknown to me but inheriting
> > from
> > a standard framework and I need to be able to see what is in there,
> > introspect it,
> > cast it to the appropriate type and work with it.
> > So I have everything inheriting from 2 classes Component and Document
> > from which
> > I could use the objectsOfClass and do the above.
> > How do you suggest that something like this could be done in a more OO
> > way through
> > the ozone API.
>
> What do you mean when you say "see what is in there" and "work with"?

I mean that i need to describe a product structure ( product-assemblies-parts )
as objects with some logic embeded along with the data but when my client
app connects to the Db, must not know anything about the product that is in there,

then scan the product and create a product manual :) that is if I'm (very) lucky
enough to get my PhD.

anyway I need to work with classes totaly unknown to the client. The client
should scan the product structure deside the objects it needs according too the
type of manual it needs to create or query to answer, interogate them
and produce the output.

> Do you
> mean you need an ad-hoc tool to check what your code produces inside the db? Or
> do you mean your app code needs to know "what is in there"?
>

I dont understand what you mean with  "what your code produces inside the db"
but I sense its not what I want  :!

>
> 1 - I agree, an ad-hoc tool would be really really cool to have.
>
> 2 - if your application needs to handle all objects of a specific class as a
> collection, then it should simply store all the objects in a collection.
>
> >
> > > It's not implemented and probably will never be implemented. It
> > perfectly
> > > doesn't fit into the ozone API.
> >
> > ok it may not be a very OO way of dealing with the situation ... but
> > give some hints on
> > a more proper solution
> See above. [I hope I got you right]
>
> The aim of the Object Server ozone is to add persistency and transactions to
> the Java object model. Nothing more, nothing less. All you can do with Java is
> also possible in ozone. If you need a collection, well, choose one and code
> away.
>
> >
> > Esteban Porcelli wrote :
> > > Is not implemented and I do not think that they are going to implement
> > it
> > > either.
> > > what you can do is have one root object with references to other
> > objects.
> >
> > we are not talking about having each object registering itself to a
> > static array attribute on
> > each object it relates somehow with ... or something else can somebody
> > explain a bit more ????
>
> No, we are just talking about OO design. Nothing freaky! ozone just holds your
> objects while the client applications are not active, that's all. You are
> trying to see more than there actually is in ozone.
>
> Ok. A Car consists of weels, engine, etc. Engine consists of ... this inturn
> consists of...  If "Car" is the basic term of your application then you simply
> give it a name in ozone and ozone will find the entire object graph of your
> application when the client starts up and asks ozone objectForName().
>

The way you put it there is a single entrance to the structure ...
If for example one is only intresated on engines he will not be able to work in
the client
with engines ... and if he needs engines he will have to go through the car to the
engine
which will be quick since the car to engine will be internal to the DB (no
transaction)
but not the sorter route from an accesibility to the object point of view.

for example in a product manual I may have the user interogating about a certain
part
or assembly only , if I try to route the request through the whole product
structure
the design will become much more complex, I think in this case things become much
simpler
if one can chose the point of entrance to the structure as well.


>
> I'm not sure but I hope this clarifies things a bit.
>
> Falko
> --
> ______________________________________________________________________
> Falko Braeutigam                              mailto:falko@smb-tec.com
> SMB GmbH                                        http://www.smb-tec.com