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

Re: Object Creation in ozone



I think you are suggesting the oodb would call the parameterless constructor
and then your app would call the other?  I do something similiar with my
construct() method.  What is needed is what Don suggested which is a method
ozone would call after the object exists, like init().

I think such an init() method could be called by the object creation thread and
work fine.  At least I cannot think of a reason why not after having looked at
the ozone code for this.


Carl Rosenberger wrote:

> Don, allow me to comment,
>
> [Business rules require a valid object network]
> > So if the valid state of 'ObjectOne' upon instantiation requires the
> > existence of another new object (the 'ObjectTwo' in my example) then it
> must
> > created from the ObjectOne constructor or created and passed to the
> > constructor.  The latter approach may require knowledge of the internals
> of
> > ObjectOne which is unacceptable.
>
> If you would neglect the necessity of storing objects in an OODB, you would
> model your business rule by only allowing a parameterized constructor.
>
> To reininstantiate objects an OODB needs a public constructor (or a VM which
> does not call the constructor when instantiating objects from persistent
> storage).
>
> > One way around this in ozone that I tried as an interim work around was a
> > 'secondary' init() method similar in purpose to Tim Brown's suggestion
> that
> > is called immediately after object creation. However this requires that an
> > object be created in an invalid state thus objects can no longer be
> > responsible for their own state.
>
> This is specific to the ozone way of letting objects "live" on the server.
> (no doubt, this system has advantages)
>
> On other OODBs you would model your rules by using constructors with
> parameters.
>
> Specifically for the OODB you would add a public constructor with zero
> parameters.
> To check your logic you could do this:
> - add a comment, that this public constructor is for the db only
> - use grep or a similar tool to make all constructors of this kind private
> - compilation should be successful
> - use grep again to restore the needed state
>
> > If one is
> > using explicit transactions it could be made to work by
> > aborting the  transaction and the object's creation.
>
> I guess, this is the correct ozone solution for your problem, but Falko will
> surely comment on that.
>
> ['ozoneInit']
> Callback functions are a common concept.
> The JDO specification proposes the following optional callbacks:
> - jdoPostLoad
> - jdoPreStore
> - jdoPreClear
>
> PreStore is what you want, but you can easily implement it yourself:
> Override the ozone commit function and call your 'ozoneInit' on all new
> objects and check the integrity there.
> A few if(... == null) should even be less work than parameterized
> constructors, because you don't have to change the entire hierarchy of your
> objects every time you add a new member.
>
> (My function's name is onCreate().)
>
> Regards,
>
> Carl Rosenberger
> db4o - database for objects - http://www.db4o.com

--
Tim Brown
URL: http://www.incenter.org