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
[EMAIL PROTECTED] said: The only problem with this is that lambdas are not safe for TTW scripting 8^(. I think that TTW scripting and heavy duty application development are very incompatible with each other, so that's not a problem :-) -- Cees de Groot http://www.cdegroot.com [EMAIL PROTECTED] GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B ___ 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 )
Re: [Zope-dev] Re: [Geeks] Interface Meta Data proposal
Jeffrey P Shell [EMAIL PROTECTED] said: But I'm not sure how one would go about setting your meta-data in a way that is at all natural to Python. I think that exceptions that a method must\should raise *should* be part of a signature\contract. This is one of the really cool things about Java. If you use a method, 'readFile' that says it raises IOError, you *HAVE* to catch that exception (I believe in order to compile). It's so cool, it really chills your productivity. The moment that Python starts doing that, I'll drop the language like a hot iron. 'Nuff about thermodynamics. Making exceptions statically checked is probably the worst misfeature of Java. The idea is nice, in that it forces you to deal with exceptions, but in reality it gets in the way too soon - when you're still exploring, refactoring, stuff like that you should be able to turn the damn things off. I've got five years of full-time Java programming behind me, so I know what I'm talking about. But it looks like what you're really wanting is to use interfaces for documentation purposes, not for contract purposes. Not for interfaces at this level of the language. Useful documentation, especially contracts, can be useful programmatically so stuff like that should at least be setup so that it is possible to move it into the language. A bit like the @pre and @post tags in Javadoc comments - they're always nice to have as documentation, but when you run iContract over them, they are activated and start checking your code's behavior. If you don't say you implement 'Cloneable', an exception gets raised (even if you implement the proper method). Another wart in Java that is nice in theory, but sits in your way in practice. I greatly prefer the Smalltalk "protocols" approach, where implementing an interface is accomplished by implementing the right methods period. The funny thing is, hardly any Smalltalk code ever checks for the interface: the (correct) assumption is that if you hand something over to some other thing that says it wants to iterate over whatever you handed over, you'd better be sure that the thing behaves at least enough like a collection so that it can be iterated over. That's the caller's responsibility (a sort of implicit precondition), and if the caller sends over something else, you get a DoesNotUnderstand exception. Very often I have longed in Java for the possibility of an object to implement a subset of behavior of another object, but that's not possible. For example, if you have a bunch of field labels you stuff in a collection just to be able to do getText()/setText() on them (say for internationalization). Now, I want to add menu labels to that collection, they also have getText()/setText() so they would be good citizens in that collection. Java does not allow that, unless I'm prepared to jump through instanceof/type casting hoops (which is only possible if I'm the one actually calling getText()/setText()). This is similar to how we sniff things today, but we just do things like 'if hasattr(obj, "cb_isCopyable") and obj.cb_isCopyable()):' The usual answer of an OO guru here is that if statements are considered harmful, and that if statements that check object types are considered very harmful. The modern variant is "these are strong refactoring smells". -- Cees de Groot http://www.cdegroot.com [EMAIL PROTECTED] GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B ___ 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: [Zope-dev] Re: [Geeks] Re: Interface Meta Data proposal
Guido van Rossum [EMAIL PROTECTED] said: When you've fully debugged an application, you turn both off. When you've fully debugged a library module, you create two versions: one with both turned off, for use in fully debugged applications, and one with pre-conditions on and post-conditions off, for use by other code that is still in need of debugging. I've heard that this works very well, and in Python 3000 (when we have optional static typing) I would love to add this to Python. If it's not feature bloat. It works very well in fully debugged applications. In the 99.99% other applications, advice is to leave the assertions on during production time so your app will fail fast when a bug pops up (profiling will point you to the two assertions that needs to be turned off for acceptable performance). Personally, but I'm talking without too much thinking here, I think support for assertions in Python should be based on generic support for metaprogramming - there's more than DBC that could benefit from that (aspect-oriented programming, etcetera). -- Cees de Groot http://www.cdegroot.com [EMAIL PROTECTED] GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B ___ 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 )
