On Jun 21, 2007, at 6:59 AM, svilen wrote:
> more questions on the theme. > What is the expected sequence / lifetime / pattern-of-usage for > engine, metadata, mappers, and finally, my objects? mappers need tables and therefore metadata, objects have mapped properties and therefore mappers. no relation to engines. > This is also related to multiplicity, e.g. can i have several > metadatas, and switch between them for same objects. the mapper is bound to a single metadata. the mapper defines a mapping between a class and a table. therefore to have mutliple metadata, you need multiple mappers, therefore you need to use entity_name. there are ways to merge() objects from one entity_name to the other. > > The only obvious rule i see is that > a) mappers must be made after metadata; not sure if that being > unbound is allowed. the metadata need not be bound to anything, it can rebind to different engines, etc. the mapper only needs a conceptual Table in order to proceed. > The other rule inferred from above problem is > b) objects lifetime should be shorter than mappers (ORM); else one > needs to delete o._instance_key and o.db_id to be able to reuse them do you mean, when you say clear_mappers() ? im not sure what the use case for that is. > > Are there other rules? i do remember about doing mappers over unbound > metadata and binding later did break certain cases. not at all. if you reuse the same Session over two different engines bound to the same set of tables without refreshing/clearing it, yes that will break. > > can i do: > 1. make metadata /unbound > 2. mappers > 3. make engine > 4. bind metadata + .create_all() > 5. objects > then unbind metadata/drop engine, then repeat 3,4,5 ? yes > > or > 1. engine > 2. metadata > 3. mappers > 4. objects > 5 metadata.drop_all() + metadata.create_all() > 6 more objects > repeat 5,6 yes > > or (current links/nodes case) > 1. objects > 2. engine > 3. metadata + createall() > 4. mappers > 5. drop everything > repeat 2,3,4,5 if by "objects" you mean "instances" and not "classes", and you mean "create new mappers each time", tricky. differerent mappers define different attributes for the objects. what happens to the state of the old attributes ? just gets thrown away ? if you can ignore that issue, just remove the _instance_key from the objects and save() them into a new session. > ... > > or (probably better way of doing it, make type-info stuff once) > 1. engine > 2. metadata + createall() > 3. mappers > 4. objects > 5. metadata.drop_all() + metadata.create_all() > 6. save same objects > repeat 5,6 yes, if you clear out the _instance_key on the objects and save() them into a new session. if its different databases youre concerned about, only the Session has any attachment to the contents of a specific database. mappers and metadata are completely agnostic to any of that, and only define *how* a class is mapped to a particular table structure...they dont care about *where*. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
