Re: [Zope-dev] ZEO on SMP
At 08:26 PM 5/23/2001 -0400, Jeremy Hylton wrote: Since a single Python process has a single global interpreter lock, you'll never fully utilize a 2-processor machine. I may be merely demonstrating ignorance, but -- If you, say, launched two separate Zope processes, and one ZEO process, on the same machine, aren't you going to be running 3 different Python interpreters, each in it's own process? Couldn't you then be utilizing up to three processors on an SMP box? I agree that threads within a particular Python interpreter are not really going to gain anything because of the global interpreter lock, but isn't that a moot point with separate Python interpreter processes? Or does the TCP/IP stack cause problems? 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
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
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 )
