Hi Michael. On Sun, 2010-04-25 at 22:32 -0400, Michael Bayer wrote:
> > > You should be able to roll this yourself as a custom dictlike > > > collection class . That's what I did :-) I wrote mostly to share my code and to suggest that this should be available out of the box. > > sorry, it seems you've done that already. I'm surprised the > > existing attribute_mapped_collection doesn't do this already ? I was surprised as well. > well, it doesn't. It should, and maybe should raise an error if the > two values don't match. It doesn't make much sense to add another > collection class to do what the first one should. Agreed. > I'm sure you noticed that you can remove the repetition by working the > other way, i.e.: > > item.note.set(Note(key="color", value="blue", desc="This should be > blue because")) > item.note.set(Note(key="shape", value="rectangular")) Indeed, although I find it unintuitive that set actually does an append/insert/add operation. Apart from that, I try to keep the mapping code and the data objects (which carry application logic) separate in case we ever want to use a non-SQL data backend (NoSQL DB, ZODB, ...). So usually, there is no set method on item.notes and there is no key property in the Note class (it's added by the mapper as _key). > also, never do this: > > class Note(object): > def __init__(self, **args): > self.__dict__.update(args) That's not production code. I just added it to get initialization in one line. > you bypass all of SQLAlchemy's history tracking logic. do this > instead: > > > class Note(object): > def __init__(self, **args): > for k, v in args.items(): > setattr(self, k, v) I usually name the possible keyword arguments explicitly as the output of help(Note) is otherwise quite unhelpful. Thanks for your reply and the remarks! Do you plan to extend attribute_mapped_collection to update the key like in my example? Be aware that this approach also has it's downside. For example, assigning item2 = Item() item2.notes['color'] = item.notes['color'] will not work contrary to what one might expect (it generated a conflict on the id column). The solution is to have the target collection copy the assigned object if it has a key already. But that might be too much magic to be easy to understand. So I think, the automatic key update should be an option. Greetings, Torsten -- DYNAmore Gesellschaft fuer Ingenieurdienstleistungen mbH Torsten Landschoff Office Dresden Tel: +49-(0)351-4519587 Fax: +49-(0)351-4519561 mailto:torsten.landsch...@dynamore.de http://www.dynamore.de Registration court: Mannheim, HRB: 109659, based in Karlsruhe, Managing director: Prof. Dr. K. Schweizerhof, Dipl.-Math. U. Franz -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
