|
From: Vincenzo Di S. <dis...@in...> - 2002-10-01 14:37:17
|
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 |