Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping
From: Joachim Werner [EMAIL PROTECTED]
This is true in the ZODB, but can be complicated by acquisition. If an
object can acquire itself, it can cause issues. Plus it becomes
difficult to know whether objects are clones or just identical
instances, although this can be mitigated by exposing their Python
instance id.
Acquisition is very cool, but it sometimes really sucks ... AFAIK you can
easily switch it off in your own Python products. But I am still
fighting
with only getting private variables (i.e. not acquired ones) in DTML ...
From DTML I have used 2 different methods for this:
1) dtml-with expr=object only
.
/dtml-with
or
2) dtml-if expr=_.hostattr(object.aq_explicit('attribute')
...
/dtml-if
In both cases 'object' is the thing with the 'private variables' and in 2),
'attribute' is the 'variable' name.
Jeff
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping
Joachim Werner wrote: Probably I'm daft because it is Friday night, but AFAIK ZODB and most OODB's store an object only once, keyed by its object id. The rest is just references through that oid, so objects that belong to more than one container can be added to all these containers and n:m relations are implemented by having a list of objects on both sides. Yes, but these references (let's call them symlinks ...) are not in the standard Zope. Of course it should be easy to do these things, but except for this from Shane I haven't seen anything so far: http://www.zope.org/Members/hathawsh/Symlink/index_html Actually I was referring to the OODB-equivalent of hard links. It's only possible from Python products / external methods / filesystem scripts / Zope core code, but here's how you do it: ob = some_folder.some_child some_other_folder.some_child = ob In other words, if you just assign an object to have multiple parents then it will just work. Changes to the object will appear to occur in both places, but really they're only occurring in one place. This behavior is fully persistent, works over ZEO, and ZODB won't even see there's anything unusual. P.S.: Shane, have you developed Symlinks any further? I think they could be extremely useful. I tried out the initial release and liked it, except for the fact that the symlinks looked EXACTLY like real ones, so they can be very irritating ... I'm not sure what to do with symlinks. How should security be applied? How are they most useful? It's neat to see it works, though. :-) Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping
From: Joachim Werner [EMAIL PROTECTED]
This is true in the ZODB, but can be complicated by acquisition. If an
object can acquire itself, it can cause issues. Plus it becomes
difficult to know whether objects are clones or just identical
instances, although this can be mitigated by exposing their Python
instance id.
Acquisition is very cool, but it sometimes really sucks ... AFAIK you can
easily switch it off in your own Python products. But I am still
fighting
with only getting private variables (i.e. not acquired ones) in DTML ...
From DTML I have used 2 different methods for this:
1)
dtml-with expr=object only
.
/dtml-with
or
2)
dtml-if expr=_.hostattr(object.aq_explicit('attribute')
...
/dtml-if
In both cases 'object' is the thing with the 'private variables' and in 2),
'attribute' is the 'variable' name.
Jeff
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping
P.S.: Shane, have you developed Symlinks any further? I think they could be extremely useful. I tried out the initial release and liked it, except for the fact that the symlinks looked EXACTLY like real ones, so they can be very irritating ... I'm not sure what to do with symlinks. How should security be applied? How are they most useful? It's neat to see it works, though. :-) Shane Last year I needed symlinks and developed a version of your product where the symlink had a different id than the real object. But the general solution of a symlink where an arbitrary set of attributes are from the symlink instance instead of from the real object was too much difficult for me, so this year we've changed the dessign of the application and don't need symlinks anymore. jdavid ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping
This is true in the ZODB, but can be complicated by acquisition. If an object can acquire itself, it can cause issues. Plus it becomes difficult to know whether objects are clones or just identical instances, although this can be mitigated by exposing their Python instance id. Acquisition is very cool, but it sometimes really sucks ... AFAIK you can easily switch it off in your own Python products. But I am still fighting with only getting private variables (i.e. not acquired ones) in DTML ... ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping
Probably I'm daft because it is Friday night, but AFAIK ZODB and most OODB's store an object only once, keyed by its object id. The rest is just references through that oid, so objects that belong to more than one container can be added to all these containers and n:m relations are implemented by having a list of objects on both sides. Yes, but these references (let's call them symlinks ...) are not in the standard Zope. Of course it should be easy to do these things, but except for this from Shane I haven't seen anything so far: http://www.zope.org/Members/hathawsh/Symlink/index_html P.S.: Shane, have you developed Symlinks any further? I think they could be extremely useful. I tried out the initial release and liked it, except for the fact that the symlinks looked EXACTLY like real ones, so they can be very irritating ... Joachim ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping
Shane Hathaway [EMAIL PROTECTED] said: That's one reason ZODB is so nice. You can write an application without writing a formal schema. One of the reasons I am seriously considering to migrate our production database from PostgreSQL to ZODB. I am about to implement our product database, and it is just too darn complex to bother maintaining SQL tables for it... Actually OracleStorage and bsddbstorage, recently released, are designed to address concerns about performance and reliability, and they do an excellent job at it. And I consider ZODB as real an OODB as anything else. (In some ways it's the best out there IMHO.) I heard that OracleStorage was quite a bit slower? And from what I've seen from FileStorage, it's a basic transaction log - what can be more reliable than that? Are people using ZODB for non-Zope data? I'd be very interested to discuss things like emulating extents, patterns for indexing, etcetera... ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping
The other motivations for an RDBMS are (1) people have existing schemas and want Zope to access the same data as their existing apps, and they want it to be transparent, and (2) tables with millions of entries are easily stored in Zope but the perception is that the catalog isn't as fast as a database index. No one has done any tests AFAIK. Then we should do these tests. E.g. I'd like to see: - 20 GB of Word and PDF documents stored in the ZODB and full-text + metadata indexed in ZCatalog - the complete [EMAIL PROTECTED] mailing list archive in the ZODB If Zope can handle those without the help of external tools (RDBMS etc.), I'll use it for all our Document Management ... That's one reason ZODB is so nice. You can write an application without writing a formal schema. Another thing (from the Slashdot article earlier this week): In Java, changes to the object structure mean recompile. In Zope, you can just do them. with working refresh support this will even work without having to restart the Zope process ... What about using a real oodb for zope? Dont remember any particular product name, but I heard something. Actually OracleStorage and bsddbstorage, recently released, are designed to address concerns about performance and reliability, and they do an excellent job at it. And I consider ZODB as real an OODB as anything else. (In some ways it's the best out there IMHO.) Agreed. ZODB has a much longer proven history of success than most other OODBs. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping
Cees de Groot wrote: Shane Hathaway [EMAIL PROTECTED] said: That's one reason ZODB is so nice. You can write an application without writing a formal schema. One of the reasons I am seriously considering to migrate our production database from PostgreSQL to ZODB. I am about to implement our product database, and it is just too darn complex to bother maintaining SQL tables for it... Actually OracleStorage and bsddbstorage, recently released, are designed to address concerns about performance and reliability, and they do an excellent job at it. And I consider ZODB as real an OODB as anything else. (In some ways it's the best out there IMHO.) I heard that OracleStorage was quite a bit slower? And from what I've seen from FileStorage, it's a basic transaction log - what can be more reliable than that? Are people using ZODB for non-Zope data? I'd be very interested to discuss things like emulating extents, patterns for indexing, etcetera... One of the biggest limitations in my mind is the lack of a general query language for the ZODB like what you get with most OODBMS and all RDBMS. ZCatalog is improving, but it is just not quite there yet. I do feel that the ZODB is quite robust, and with the added option of berkeley storage along with others, you have several back-end choices. -- | Casey Duncan | Kaivo, Inc. | [EMAIL PROTECTED] `-- ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping
At 11:45 AM 5/11/2001 -0600, Casey Duncan wrote: One of the biggest limitations in my mind is the lack of a general query language for the ZODB like what you get with most OODBMS and all RDBMS. I used to think this as well. But isn't Python a decent query language? Isn't it nice to be able to have all of the facilities of Python at your disposal when manipulating data, rather than hoping that whatever database you are using doesn't have a brain-damaged implementation of SQL? Isn't it nice not to have to convert back and forth between SQL types and native types? Isn't it nice not to have to swap in your SQL mind in the middle of your Python program? Having a general query language makes it easy for people who know that particular general query language to write programs. It makes it easy to access a bunch of different data sources, at least until the monster named implementation differences rears it's ugly head. We've all spent years learning to make our programs interface with databases, learning how to jump the mental chasm between our programs and they way they want to manipulate data, and the way that the database wants to manipulate data. Isn't it nice not to have to do that any more? Don't get me wrong, I believe I get your point. SQL implementations are getting more and more compatible. There are OODBMS query languages specified. There's no really good way of making different programming languages and programming environments interoperate without some sort of common meeting ground, like a general query language. And perhaps I'm overdoing the response, perhaps I've gone off in a different direction. I've just been thinking about this quite a bit lately. dave ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping
But isn't Python a decent query language? Isn't it nice to be able to have all of the facilities of Python at your disposal when manipulating data, rather than hoping that whatever database you are using doesn't have a brain-damaged implementation of SQL? Most of the time nobody will need SQL. And having a transparent, transaction-aware and undoable persistent Object store is really a cool thing. But from time to time you will hit walls. That's when the object paradigm just does not do the job completely well any more. E.g. how would you handle objects beloning to more than one container? In SQL this is easy (Just have a table that matches key pairs from the container table and the item table). And I don't know any good way of implementing many-to-many relations in object hierarchies. Let alone querying them efficiently. Joachim ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping
At 08:38 PM 5/11/2001 +0200, you wrote: E.g. how would you handle objects beloning to more than one container? In SQL this is easy (Just have a table that matches key pairs from the container table and the item table). I could do the same thing with Python, creating a dictionary that does the mapping. You'd have to maintain the dictionary, sure, but you'd have to maintain the table in a relational database as well. And I don't know any good way of implementing many-to-many relations in object hierarchies. Let alone querying them efficiently. Well, then we need a many-to-many mapping object. The point is that we could do this in Python and make the classes available, rather than morphing our thought processes into whatever shape the RDBMS wants. We're just missing some functionality, but it can be written without rewriting the database code, because we can just store our objects (representing indices or mappings or whatever) directly. The cool thing about object stores is that you can use the object modeling tools to do the job, and come up with specific (and more efficient) solutions, rather than mapping a general (and possibly slower) solution onto a specific problem. dave ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping
Joachim Werner [EMAIL PROTECTED] said: [...]. E.g. how would you handle objects beloning to more than one container? In SQL this is easy (Just have a table that matches key pairs from the container table and the item table). And I don't know any good way of implementing many-to-many relations in object hierarchies. Let alone querying them efficiently. Probably I'm daft because it is Friday night, but AFAIK ZODB and most OODB's store an object only once, keyed by its object id. The rest is just references through that oid, so objects that belong to more than one container can be added to all these containers and n:m relations are implemented by having a list of objects on both sides. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping
Hi shane, I think the motivation people want an RDBMS storage beneth zodb is because they understand RDBMSes these days are performant, relieable and can quiete easy maintained. I've seen Java implementations using this approach to achive persistens using as example Powertier[tm] to explicit map oop data to an RDBMS. I didnt like it because you have to map your objects each time you create a class, keep in mind not to infere with others etc... Would it not be better to improve the abilities of the Filestorage to handle updates better? May be most of the storage system in C? With logfiles like modern RDBMSes use to incorporate fast changes? However, to avoid pickling/unpickling and may be to update on attribute-change, we need the approach you mentioned. What about using a real oodb for zope? Dont remember any particular product name, but I heard something. Regards Tino Wildenhain --On Donnerstag, 10. Mai 2001 12:39 -0400 Shane Hathaway [EMAIL PROTECTED] wrote: Tino Wildenhain wrote: But storage of binary pickles was never the intention anyway. I created a little interface that would allow you to store different classes in different PostgreSQL tables. Before I got to implementing anything, Is this much like the ZPatterns approach? Which part of ZPatterns are you referring to? The idea is to (generally) put all instances of a class in a certain table. But the implementation details having nothing in common with ZPatterns. Or do we want to make some automatism to get tables created and destroyed according to ZClasses needs? I was thinking there would be a default table where everything gets stored by default. A programmer then tells the ORMapping about specific classes and how to store them. So, if we have context, the relational mapping tree can work. It would turn Zope into a purely relational application server, which a lot of folks apparently want. ;-) Oh, do they? ;) Me dont :-) You know, it might be possible to get a team together to implement this. How many out there would be interested in pursuing it further? IMHO it's not as much work as it sounds at first. Zope being so object-oriented, you really can replace one of its most fundamental assumptions (an OODBMS) with something else (an RDBMS) without a huge effort. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping
Tino Wildenhain wrote: I think the motivation people want an RDBMS storage beneth zodb is because they understand RDBMSes these days are performant, relieable and can quiete easy maintained. The other motivations for an RDBMS are (1) people have existing schemas and want Zope to access the same data as their existing apps, and they want it to be transparent, and (2) tables with millions of entries are easily stored in Zope but the perception is that the catalog isn't as fast as a database index. No one has done any tests AFAIK. I've seen Java implementations using this approach to achive persistens using as example Powertier[tm] to explicit map oop data to an RDBMS. I didnt like it because you have to map your objects each time you create a class, keep in mind not to infere with others etc... That's one reason ZODB is so nice. You can write an application without writing a formal schema. Would it not be better to improve the abilities of the Filestorage to handle updates better? May be most of the storage system in C? With logfiles like modern RDBMSes use to incorporate fast changes? However, to avoid pickling/unpickling and may be to update on attribute-change, we need the approach you mentioned. What about using a real oodb for zope? Dont remember any particular product name, but I heard something. Actually OracleStorage and bsddbstorage, recently released, are designed to address concerns about performance and reliability, and they do an excellent job at it. And I consider ZODB as real an OODB as anything else. (In some ways it's the best out there IMHO.) Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping
Tino Wildenhain wrote: Hi shane, I think the motivation people want an RDBMS storage beneth zodb is because they understand RDBMSes these days are performant, relieable and can quiete easy maintained. I've seen Java implementations using this approach to achive persistens using as example Powertier[tm] to explicit map oop data to an RDBMS. I didnt like it because you have to map your objects each time you create a class, keep in mind not to infere with others etc... Would it not be better to improve the abilities of the Filestorage to handle updates better? May be most of the storage system in C? With logfiles like modern RDBMSes use to incorporate fast changes? However, to avoid pickling/unpickling and may be to update on attribute-change, we need the approach you mentioned. What about using a real oodb for zope? Dont remember any particular product name, but I heard something. Regards Tino Wildenhain It would certainly be an interseting exercise to put Matisse or Objectivity behind Zope as ZODB storage, however I think there will always be kludgeyness because features of Zope wont directly map (like versions). I think the Berkeley storage option will eventually prove to be the ticket. Probably sooner than later. How about XML storage! 8^) You think startup times are slow now... -- | Casey Duncan | Kaivo, Inc. | [EMAIL PROTECTED] `-- ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
