On Nov 16, 2010, at 12:05 PM, A.M. wrote: > >> 2. implicit conversion to JSON and such is a little sloppy. You'd be >> better off using a structured approach like Colander: >> http://docs.repoze.org/colander/ > > It looks like I would have to either re-define all objects using the Colander > syntax or implement a method which converts existing SQLAlchemy models to > Colander schema objects. Even if the latter function already exists, I still > have the problem of determining automatically which properties to encode, no?
Jek's suggestion is good here, also in my experience when I need to use JSON for something, it implies I'm communicating with some other system that doesn't know about my mapped objects - meaning, even if the JSON structure is initially driven by the ORM completely, I need the JSON structure to remain independent of changes in the ORM model in any case. But usually I'm dealing with a service that looks dramatically different from my ORM models anyway. Its again the same dichotomy in SQLAlchemy itself, "your json messages are not your domain objects" ;) I haven't used Colander and instead have something homegrown - a core feature is that it maintains a mapping of object attributes, in some cases dot-separated paths, to field names that would be generated in JSON or XML. I also use it to translate against .csv and .xls formats. Most apps I work on end up that way, so I go straight to explicit mappings up front since I know the variability is going to be great. -- 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.
