Thanks - this is exactly the information I was looking for! On 10/21/06, Michael Bayer <[EMAIL PROTECTED]> wrote: > > MapperExtension allows you to override the select() and select_by() > methods of Query, and in the trunk it also supports get_by(), get(), > and load(). this would be a place to put a very coarse-grained bypass > of querying in. this is something you could do pretty quickly without > getting too deeply into things.
That sounds like it might be a good step one. > if you want your instances to be more integrated with the unit of work, > that would be much more involved and im not sure if anything would > really be left of the ORM once you completed it, particularly if they > truly have no correlation to a table at all. Well I definitely want to be more integrated. The thing I'm trying to integrate still is a database and has tables and transactions - I'm just trying to bypass SQL itself. The MySQL Cluster product (NDB) has a direct C++ API that I've been wrapping with Python. I'm working on this theory that the direct interface actually maps really nicely to ORM concepts better than generating SQL (which in small tests it does), but I thought it would be nice to work from an already exisiting ORM than to write my own. We need another ORM like we need a hole in the head. The down side is what you mention, though. Most ORM's aren't just desinged to provide a relational persistence layer for objects, they are also designed around SQL. And why shouldn't they be? What other readily available mechanism do we have for RDBMS interface? So It may be that I've got to rip out too much and write my classes too far up the chain. Still may be good, though. I'll post what I get working when I do. Thanks, Monty > MapperExtension has a lot of methods that fire off upon insert, update, > delete, etc that would probably be involved. *maybe* a careful usage > of those could accomplish most of the task. > > Youd probably want to get fairly familiar with the internals of how > mapped objects are set up. this would mostly involve carefully > inspecting the __dict__ of instances as they move through various > persistence states, familiarizing yourself with the instances() method > on Query (its been recently moved from Mapper to Query) as well as the > _instance(), save_obj() and delete_obj() methods on mapper, and getting > a general idea of the purpose of the attributes.py module which is > something you can play with all by itself (see the attributes.py test > suite in the test/ directory for examples). > > I would say its worth putting some thought into the motivations for > putting file-based persistence behind SQLAlchemy's API, since > SQLAlchemy itself is designed to be explicitly revealing of database > concepts, intending to be placed behind coarser-grained persistence > layers for applications that want to conceal the details of SQL > database interaction. such a layer would probably be a better place to > stick an abstraction between SQL and file-based persistence. > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy -~----------~----~----~----~------~----~------~--~---
