Re: [Openflow-dev] Re: Datas in a database (was Re: [Openflow-dev] zpt)

[Vincenzo Di S. <dis...@in...>]

I`m struggling on the reason why we need to store the workflow objects in=
 a=20
relational db, but at the moment I can`t find a good a good one.

On Friday 27 September 2002 16:59, Juli=E1n Mu=F1oz wrote:
> An option would be then to store the properties on the zodb (=3Dthe
> instance would be derived from PropertyManager), and in the db would be
> stored the remaining attributes (the ones to locate the instance in the
> db)... I'll keep on thinking on this
>
> On Fri, 27 Sep 2002, Juli=E1n Mu=F1oz wrote:
> > Hi,
> >
> > finally I start to understand DBObjects.
> >
> > A bit hard... The conclusion is that it is possible to implement obje=
cts
> > in a database (in our case, 2 classes: instances and workitems). If
> > someone (me?) read this on the future, I hope this will help:
> >
> >
> > It seems that with DBObjects:
> >
> > - each class must have a predefined set of attributes
> > - these attributes aren't properties (DBObjects aren't
> > derived form PropertyManager).
> >
> > So it's clear that an instance can't be a DBObject, because it's not
> > generic enough.
> >
> > However there is FolderishDBObjects, which can contain DBObjects, so =
it
> > would be possible to implement properties (one DBObject per property)=
=2E
> >
> > Well, from the point of view of database connection, dynamic tables
> > creation, I have no idea of how factible it is (DBObject requires
> > postgree sql and the correspondente ZopeDA, and I haven't installed i=
t).
> >
> > So this is too much work for the moment, I'll keep on using the syste=
m I
> > have now :-)
> >
> > On Wed, 25 Sep 2002, Vincenzo Di Somma wrote:
> > > On Wednesday 25 September 2002 18:15, Juli=E1n Mu=F1oz wrote:
> > > > On Wed, 25 Sep 2002, Vincenzo Di Somma wrote:
> > > > > > I would be very much interested in features like separating t=
he
> > > > > > datas of the Openflow (instances and workitems) in a database=
=2E
> > > > >
> > > > > Any proposal about that ?
> > > >
> > > > Using something like:
> > > >
> > > > http://www.zope.org/Members/srichter/Products/DBObjects
> > > > http://sf.net/projects/modeling
> > > >
> > > > But reading the first one has given me a gread headache. It's a
> > > > complex topic.
> > > >
> > > > Well from what I read from DBOBjects, it seems to be convenient t=
o
> > > > have a trace of the object in the zodb.
> > > >
> > > > You put the database adapter on the Openflow, and it regenerates =
the
> > > > object structure.
> > > >
> > > > Then, you work transparently.
> > > >
> > > > One point would be: if you delete the openflow, the objects would=
 not
> > > > be deleted from the database.  If you replace the openflow with a=
nd
> > > > upgrade, it will still use the objects on the database, and will =
not
> > > > alterate them.
> > >
> > > We hope to fix the interfaces NOW :) So for the next release it wil=
l be
> > > very very easy to upgrade running OpenFlow objects, your product wi=
ll
> > > be very useful :)
> > >
> > > > Well, I don't know, maybe a simpler solution would be possible, b=
ut,
> > > > how would you attach a property to an instance ? All seem to poin=
t to
> > > > something like this.
> > >
> > > I prefer instead to use the standard zope property manager properti=
es
> > > or instantiate custom o standard objects in the process instance, b=
ut
> > > if in your experience you`ve found it not confortable we can try to
> > > find another solutions. However when I need interaction between a
> > > process instance and one or more RDMS tables I store the primary ke=
ys
> > > in the instance and I use them to retrive information form the DB.
> > >
> > > > Just ideas, for the future :-)
> > >
> > > Thanks a lot  :)
> > > 	Vincenzo.
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Openflow-dev mailing list
> > > Ope...@li...
> > > https://lists.sourceforge.net/lists/listinfo/openflow-dev