From jeremy at alum.mit.edu Fri Sep 12 11:19:45 2003 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Fri Sep 12 11:19:58 2003 Subject: [Persistence-sig] SIG retirement Message-ID: <1063379984.2069.276.camel@localhost.localdomain> The persistence SIG is schedule to retire this month. There has been no significant activity here since Nov. 2002. I know there are several active persistence projects, but this SIG doesn't seem to have become a forum for any of them. If you don't want the SIG to be retired, please speak up now. Jeremy From pobrien at orbtech.com Fri Sep 12 11:51:42 2003 From: pobrien at orbtech.com (Patrick K. O'Brien) Date: Fri Sep 12 11:51:02 2003 Subject: [Persistence-sig] SIG retirement In-Reply-To: <1063379984.2069.276.camel@localhost.localdomain> References: <1063379984.2069.276.camel@localhost.localdomain> Message-ID: Jeremy Hylton writes: > The persistence SIG is schedule to retire this month. There has > been no significant activity here since Nov. 2002. I know there are > several active persistence projects, but this SIG doesn't seem to > have become a forum for any of them. If you don't want the SIG to > be retired, please speak up now. As the leader of one very active persistence project[1], I'd love to discuss some of the issues I've run into. Particularly since I've recently come up with what I think are some pretty innovative solutions to problems like alternate keys, referential integrity, bi-directional links, schema evolution, and so forth. Is anyone else interested in Python persistence or a Python ODBMS, like ZODB or PyPerSyst? If so, let's talk. [1] PyPerSyst, a Python ODBMS: http://www.orbtech.com/wiki/PyPerSyst -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- From jeremy at alum.mit.edu Fri Sep 12 13:31:25 2003 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Fri Sep 12 13:31:44 2003 Subject: [Persistence-sig] SIG retirement In-Reply-To: References: <1063379984.2069.276.camel@localhost.localdomain> Message-ID: <1063387884.2069.283.camel@localhost.localdomain> On Fri, 2003-09-12 at 11:51, Patrick K. O'Brien wrote: > As the leader of one very active persistence project[1], I'd love to > discuss some of the issues I've run into. Particularly since I've > recently come up with what I think are some pretty innovative > solutions to problems like alternate keys, referential integrity, > bi-directional links, schema evolution, and so forth. > > Is anyone else interested in Python persistence or a Python ODBMS, > like ZODB or PyPerSyst? If so, let's talk. Perhaps this question should be asked on python-list. Jeremy From donnalcwalter at yahoo.com Sat Sep 13 06:33:11 2003 From: donnalcwalter at yahoo.com (Donnal Walter) Date: Sat Sep 13 06:33:14 2003 Subject: [Persistence-sig] SIG retirement In-Reply-To: Message-ID: <20030913103311.73232.qmail@web13902.mail.yahoo.com> --- "Patrick K. O'Brien" wrote: > Jeremy Hylton writes: > > If you don't want the SIG to be retired, please speak up now. > > As the leader of one very active persistence project[1], I'd love > to discuss some of the issues I've run into. Particularly since > I've recently come up with what I think are some pretty > innovative solutions to problems like alternate keys, referential > integrity, bi-directional links, schema evolution, and so forth. > > Is anyone else interested in Python persistence or a Python > ODBMS, like ZODB or PyPerSyst? If so, let's talk. > > [1] PyPerSyst, a Python ODBMS: > http://www.orbtech.com/wiki/PyPerSyst I am interested in persistence issues and have been actively working on a project to provide persistence for a custom GUI application development framework (Mindwrapper). The reason I have not posted to this SIG is that the early discussion here was on a plane several orders of magnitude higher than my own project. If discussion here were to pick up I would follow it with interest, but I likely would not participate much more actively than I have been to date. I have also followed PyPerSyst with some interest, but to this point I can't see how to integrate it into the Mindwrapper framework. Regards, ===== Donnal Walter Arkansas Children's Hospital From pobrien at orbtech.com Sat Sep 13 08:20:20 2003 From: pobrien at orbtech.com (Patrick K. O'Brien) Date: Sat Sep 13 08:19:39 2003 Subject: [Persistence-sig] SIG retirement In-Reply-To: <20030913103311.73232.qmail@web13902.mail.yahoo.com> References: <20030913103311.73232.qmail@web13902.mail.yahoo.com> Message-ID: Donnal Walter writes: > --- "Patrick K. O'Brien" wrote: > > > > As the leader of one very active persistence project[1], I'd love > > to discuss some of the issues I've run into. Particularly since > > I've recently come up with what I think are some pretty > > innovative solutions to problems like alternate keys, referential > > integrity, bi-directional links, schema evolution, and so forth. > > > > Is anyone else interested in Python persistence or a Python > > ODBMS, like ZODB or PyPerSyst? If so, let's talk. > > > > [1] PyPerSyst, a Python ODBMS: > > http://www.orbtech.com/wiki/PyPerSyst > > I am interested in persistence issues and have been actively > working on a project to provide persistence for a custom GUI > application development framework (Mindwrapper). The reason I have > not posted to this SIG is that the early discussion here was on a > plane several orders of magnitude higher than my own project. If > discussion here were to pick up I would follow it with interest, > but I likely would not participate much more actively than I have > been to date. I have also followed PyPerSyst with some interest, > but to this point I can't see how to integrate it into the > Mindwrapper framework. Oh, it will happen eventually. PyPerSyst: All your entity are belong to us! ;-) And I guess that makes me the Pyd Pyper... http://www.ims.uni-stuttgart.de/~jonas/piedpiper.html -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- From donnalcwalter at yahoo.com Sat Sep 13 13:20:22 2003 From: donnalcwalter at yahoo.com (Donnal Walter) Date: Sat Sep 13 13:20:26 2003 Subject: [Persistence-sig] terminology for entity-type Message-ID: <20030913172022.23133.qmail@web13902.mail.yahoo.com> Having never been a DBA, sometimes I have trouble coming up with accurate terminolgy for things that I have implemented. I thought I might take advantage of these lists and ask what may be a naive question, but any advice would be much appreciated. If one has a collection (set) of data-entities, each of which is of the same class, what do you call that class relative to the data collection? For example, let's say that we have a set of medication orders (named, say, MedList, even though it is not a true list), with every item of the set being an instance of the class MedOrder. I'd like to say that the class MedOrder is the _______ of the set MedList. I have used the word *domain* ("MedOrder is the domain of MedList"), but in the little reading that I have done, "domain" seems to be related to a column rather than to a row. Likewise for "extent", although I'm still not sure I understand extents. Thanks, ===== Donnal Walter Arkansas Children's Hospital From pobrien at orbtech.com Sat Sep 13 15:45:32 2003 From: pobrien at orbtech.com (Patrick K. O'Brien) Date: Sat Sep 13 15:45:03 2003 Subject: [Persistence-sig] Re: [PyPerSyst-Devel] terminology for entity-type In-Reply-To: <20030913172022.23133.qmail@web13902.mail.yahoo.com> References: <20030913172022.23133.qmail@web13902.mail.yahoo.com> Message-ID: Donnal Walter writes: > If one has a collection (set) of data-entities, each of which is of > the same class, what do you call that class relative to the data > collection? Most OO people don't. Most call the class an Entity. And the set of all instances of a particular Entity class (such as your MedOrder entity class) is usually called an extent. Unfortunately, extents get short-changed in the academic literature, imo. If you look at PyPerSyst you'll see that I have an actual Extent class that does most of the hard work. Here is a little table of terms that might be useful: OO Relational Theory Typical DBMS ------------ ----------------- ------------------ extent relation table entity class ??? SQL DDL instance tuple row attribute attribute column or field Most people make the mistake of thinking that the entity class and the relational table are the common elements. They are not. It is the extent that is most similar to the relational table. The entity class is most like the SQL DDL, ie, the Create Table statements. Overlook this at your own peril. ;-) [I no longer have any Codd & Date books, so I'm a little fuzzy on exactly how they define "relation" and "tuple", and whether they have a term for the concept embodied by an OO class. But I'm willing to bet I'm pretty close.] > For example, let's say that we have a set of medication orders > (named, say, MedList, even though it is not a true list), with every > item of the set being an instance of the class MedOrder. I'd like > to say that the class MedOrder is the _______ of the set MedList. I don't know what you'd call it, because you're phrasing it in the reverse order of how and entity and its extent are typically described. For example, you usually have one Entity class for each major "thing" in your application domain, such as: Person, Organization, Order, OrderDetail, Product, Employee, etc. Then you would say something like "The Person extent is the set of all instances of the Person class." And extents usually go without a name. In PyPerSyst, the extent instance for a particular class is just an instance of Extent, and the instance is a class level attribute of the particular Entity subclass. In your case I would create something like this: class MedOrder(Entity): ... And then the extent (which gets hooked up and maintained behind the scenes by PyPerSyst) can be referenced in two ways. The first way is as an attribute of the MedOrder class (via one of its instances): # Use the Create transaction. t = tx.Create('MedOrder', med='Foo', date='09-13-2003') # Execute the transaction, which returns a MedOrder instance. mo = db.execute(t) # Reference the extent. mo.extent.someMethodProvidedByExtent ... The second way, which is actually the more common case, is to access the extent from the database root (all branches point to an extent instance): # Get the MedOrder extent. extent = db.root['MedOrder'] # Do something with it, like find all orders for the 'Foo' med. orderList = extent.find(med='Foo') for order in orderList: print order.date ... > I have used the word *domain* ("MedOrder is the domain of MedList"), > but in the little reading that I have done, "domain" seems to be > related to a column rather than to a row. Likewise for "extent", > although I'm still not sure I understand extents. Domain is most often used in two ways. It is used in a casual way to refer to the scope of your application, which in your case might be the medical management domain, or physician treatment domain. It is also used more formally, particularly in relational theory, to refer to the set of all possible valid values for a field/column. This is to distinguish the concept of field domain from field datatype. Two fields may have the same datatype (say, string with a length of 20 characters), and the same purpose (perhaps a Name field), but that doesn't mean they represent the same domain. For example, let's say we had a Person table and a Building table, both of which had Name fields specified in SQL as CHAR(20). The domain (set of all possible valid values) for a Person Name is not the same as the domain for a Building Name. What that means is that comparisons between the two fields are not necessarily meaningful. Did that help? -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- From donnalcwalter at yahoo.com Sat Sep 13 19:41:22 2003 From: donnalcwalter at yahoo.com (Donnal Walter) Date: Sat Sep 13 19:41:29 2003 Subject: [Persistence-sig] Re: [PyPerSyst-Devel] terminology for entity-type In-Reply-To: Message-ID: <20030913234122.63846.qmail@web13903.mail.yahoo.com> --- "Patrick K. O'Brien" wrote: > > Did that help? Yes, Patrick, thank you. To start with, it is clear that "domain" won't work (for what I have in mind), which is as I suspected. Secondly, yes I did understand that the entity class does NOT correspond to the relational table: > Most people make the mistake of thinking that the entity class > and the relational table are the common elements. They are not. > It is the extent that is most similar to the relational table. > The entity class is most like the SQL DDL, ie, the Create Table > statements. Overlook this at your own peril. ;-) > > Donnal Walter writes: > > > If one has a collection (set) of data-entities, each of which > > is of the same class, what do you call that class relative to > > the data collection? > > Most OO people don't. Most call the class an Entity. And > the set of all instances of a particular Entity class (such > as your MedOrder entity class) is usually called an extent. > Unfortunately, extents get short-changed in the academic > literature, imo. If you look at PyPerSyst you'll see that I > have an actual Extent class that does most of the hard work. On the other hand, I had not previously heard the term "extent". Is this your term? Or can you point me to some additional reading? I take it that there probably is not a lot written about it. In any case, I would not have thought of the extent as being an attribute of the entity. That is because the Mindwrapper schema framework is hierarchical (which carries with it obvious limitations regarding many-to-many relationships). In this framework, there could be many instances of MedList each of which has an element type of MedOrder. In this case it is more natural IMO to think of MedOrder as being a class attribute of MedList, not the other way around. > I don't know what you'd call it, because you're phrasing it in > the reverse order of how and entity and its extent are typically > described. For example, you usually have one Entity class for > each major "thing" in your application domain, such as: Person, > Organization, Order, OrderDetail, Product, Employee, etc. Then > you would say something like "The Person extent is the set of > all instances of the Person class." And extents usually go > without a name. > > In PyPerSyst, the extent instance for a particular class is > just an instance of Extent, and the instance is a class level > attribute of the particular Entity subclass. In your case I > would create something like this: > > class MedOrder(Entity): > ... Yes, I would do the same (or the equivalent thereof). Then in Mindwrapper I would add: class MedList(Table): elementclass = MedOrder # or some better name for class attr > And then the extent (which gets hooked up and maintained behind > the scenes by PyPerSyst) can be referenced in two ways. The > first way is as an attribute of the MedOrder class (via one of > its instances): > > # Use the Create transaction. > t = tx.Create('MedOrder', med='Foo', date='09-13-2003') > # Execute the transaction, which returns a MedOrder instance. > mo = db.execute(t) > # Reference the extent. > mo.extent.someMethodProvidedByExtent > ... > > > The second way, which is actually the more common case, is to > access the extent from the database root (all branches point > to an extent instance): > > # Get the MedOrder extent. > extent = db.root['MedOrder'] > # Do something with it, like find all orders for the 'Foo' med. > orderList = extent.find(med='Foo') > for order in orderList: > print order.date In Mindwrapper, there are two similar mechanisms. The first way is to call GetParent() via the element itself. tbl = mo.GetParent() tbl.someMethodProvidedByTable The second way, which is the more common case, is to access the table from the database root: tbl = db.patient.MR615431.ptdata.medlist #Do something with it, like sort by the date started orderList = tbl.GetByField('startTime') for order in orderList: print order.startTime I recognize the limitations of a hierarchical framework, but for nearly all of the small to medium-sized clinical applications I am hoping to build it is nearly ideal. This is because this framework provides an easy mechanism for defining row- and table-valued attributes (columns). Does PyPerSyst allow for complex attributes (other Entity instances) in the Entity definition, for example, or must all attributes be scalar? Thanks again and kindest regards, ===== Donnal Walter Arkansas Children's Hospital From pobrien at orbtech.com Sat Sep 13 21:32:49 2003 From: pobrien at orbtech.com (Patrick K. O'Brien) Date: Sat Sep 13 21:32:14 2003 Subject: [Persistence-sig] Re: [PyPerSyst-Devel] terminology for entity-type In-Reply-To: <20030913234122.63846.qmail@web13903.mail.yahoo.com> References: <20030913234122.63846.qmail@web13903.mail.yahoo.com> Message-ID: Donnal Walter writes: > --- "Patrick K. O'Brien" wrote: > > > > Did that help? > > Yes, Patrick, thank you. To start with, it is clear that "domain" > won't work (for what I have in mind), which is as I suspected. > > Secondly, yes I did understand that the entity class does NOT > correspond to the relational table: I didn't mean to imply that you didn't. I was just up on my soapbox. [snip] > On the other hand, I had not previously heard the term "extent". Is > this your term? Or can you point me to some additional reading? No, it is pretty common in the literature. Try a Google search: http://www.google.com/search?q=odbms+extent CiteSeer is a good resource for academic papers: http://citeseer.nj.nec.com/ Here is a very good report on both the concepts and commercial ODBMS offerings: http://www.dacs.dtic.mil/techs/oodbms2/oodbms2.pdf Here is a decent introduction to ODBMS by Doug Barry: http://www.service-architecture.com/object-oriented-databases/index.html And here he compares terminology: http://www.service-architecture.com/database/articles/comparison_of_object_and_relational_terminology.html But take Barry's writing with a grain of salt, because he makes the classic mistake of thinking that a Class is like a Relation, he doesn't even mention the class extent in his diagram, and he makes too much of inheritance, which should be avoided in Entity classes. > I take it that there probably is not a lot written about it. It isn't a lack of mention of extents in the literature, it's a lack of understanding of just how useful an extent object can be. Most writers treat the extent as a simple collection that merely keeps track of the instances of a given class. And while that may be all that it is in some databases, I have found that giving it some muscle can be extremely useful. In PyPerSyst, the Extent class has more lines of code than any other class. > In any case, I would not have thought of the extent as being an > attribute of the entity. It is a class attribute (as opposed to an instance attribute) of the Entity class. That is how the class constructor knows what to do with new instances (it gives them to the extent). The extent instances are also assigned to the database root object, and are persistent. In PyPerSyst, they behave similarly to Relational tables. Does that make sense? > That is because the Mindwrapper schema framework is hierarchical > (which carries with it obvious limitations regarding many-to-many > relationships). In this framework, there could be many instances of > MedList each of which has an element type of MedOrder. In this case > it is more natural IMO to think of MedOrder as being a class > attribute of MedList, not the other way around. You can represent hierarchical relationships in PyPerSyst, you just don't structure your schema that way. The schema stays "flat". [snip] > I recognize the limitations of a hierarchical framework, but for > nearly all of the small to medium-sized clinical applications I am > hoping to build it is nearly ideal. This is because this framework > provides an easy mechanism for defining row- and table-valued > attributes (columns). Does PyPerSyst allow for complex attributes > (other Entity instances) in the Entity definition, for example, or > must all attributes be scalar? On one level, PyPerSyst will let you do whatever you want. But I've added an entity package that provides the behaviors I need, which I've been describing. And I expect other developers will add components that do things the way they prefer. As far as use of the entity package goes, Entity attributes are expected to be scalar. But you can still have regular Python references as attributes. So with the proper schema you should be able to represent any kind of relationship: flat, hierarchical, network. Your PyPerSyst schema would just look a lot different that a Mindwrapper schema. But if it couldn't easily support the same kinds of applications that you describe, I will have failed because I want it to be easy to create any kind of persistent application in PyPerSyst. You may have to follow certain conventions, but it should still be easy, clean, elegant, and powerful. That's my goal. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." -----------------------------------------------