Hi Ian, welcome to the team :) I agree that it would be nice if our "business logic" was split from basic database access layer. However, for all intents and purposes, I want to vouch against "more ORM-like" approach (mostly because Storm does allow us to get the best out of the database, and I am talking as someone who has seen that querying on "something" or "something IS TRUE" in Postgres doesn't hit the same indexes).
And not the least, object mapping can not express relational concepts that SQL (and Storm) can. When it comes to nailing down that last bit of performance problem, we'll have to resort to it anyway (or we'll create an ORM layer that will basically be as complex and expressive as Storm, when the question pops up: why bother?). У пет, 27. 08 2010. у 07:48 +1200, Robert Collins пише: > ... interface conformance testing ... This is something I found missing from the discussion here: interfaces. Compared to Java and Hibernate approach, we do have interfaces which are definitions of how an object would look like. And we do have both database- and memory-backed objects implementing same interfaces (eg. we've got POFile and DummyPOFile objects) or multiple database-backed objects implementing same interfaces. In essence, we've been doing this but without implementing mock objects for testing as well. It wouldn't be too far fetched to go that route, and we can already do it. Still, lots of our tests test things that do depend on persistence and specifics of our data storage (like query-count assertions, trigger-dependent code, hitting constraints and similar). Perhaps that's not really "unit-testing", but I don't want to argue over semantics: these are some of our most important tests. While interfaces in Python are mostly a replacement for some other features of statically compiled languages like Java, I fear that we'd be structuring our code in a too complex nature: Interface -> DAO -> Interface -> Model -> View -> Template (because eventually, it's going to be hard for us to resist the urge to treat multiple DAO classes as one 'type') One can say how this is not overly complex, but then again, we've already got a lot of confusion with security boundaries, we do a lot of "mixins", and we also have adapters for Zope "layers", like TranslationsPerson vs Person. It has long been agreed that this is the approach to take (i.e. split model classes by intent as well), which would complicate our code base even further. In my opinion, this approach (where you split out all the code from model classes into "registry", "code", "soyuz", "translations"... classes) would almost make the need for separate DAO classes — well, non-existent. And if the tides are changing and this is not going to be recommended way to split code out, then we need to think about the same thing at the same time. I am not saying it wouldn't be nice to split database model out, I am just saying that there's a lot more to it that needs to be taken into consideration before we can call out "victory!". Cheers, Danilo _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
