I briefly went through the source, and am not sure if it support InheritableSQLObject. Because my limited understanding is that sqlmeta only contains the columns for that table, but not what it "inherit" from.
BTW, thanks for adding the ignore_key_missing flag. Ian Bicking wrote: > I added a new module to FormEncode in formencode.sqlschema, which wraps > SQLObject classes/instances in a schema, and does the create/update/read > as part of the .from_python/.to_python methods. I think it's really > cool, and should make editing SQLObject objects way more elegant and easy. > > I don't know why this hasn't occurred to me before, because it makes so > much sense, and builds really well on the FormEncode features that were > already there. It doesn't bind a SQLObject class to a specific schema > -- the schema isn't intended to be attached to a particular form or line > of input (it could be any external source of data, really, including > GUIs, XMLRPC, etc). However, the schemas can be really short, and > really you only have to add information to them as you make the form > look more or less like the original class. > > I'm sure there's stuff to be worked out, and I have to spend some time > really using this to see how it goes. But I'm pretty excited about it. > Not counting actual form generation, I think this advances CRUD for > SQLObject significantly. > > I'll copy the docstring below: > > class SQLSchema(schema.Schema): > > """ > SQLSchema objects are FormEncode schemas that are attached to > specific instances or classes. > > In ``.from_python(object)`` these schemas serialize SQLObject > instances to dictionaries of values, or to empty dictionaries > (when serializing a class). The object passed in should either be > None (new or default object) or the object to edit. > > In ``.to_python`` these either create new objects (when no ``id`` > field is present) or edit an object by the included id. The > returned value is the created object. > > SQLObject validators are applied to the input, as is notNone > restrictions. Also column restrictions and defaults are applied. > Note that you can add extra fields to this schema, and they will > be applied before the SQLObject validators and restrictions. This > means you can use, for instance, ``validators.DateConverter()`` > (assigning it to the same name as the SQLObject class's date > column) to have this serialize date columns to/from strings. > > You can override ``_invoke_to_python`` to change the actual > instantiation. > > The basic idea is that a SQLSchema 'wraps' a class or instance > (most typically a class). So it would look like:: > > class PersonSchema(SQLSchema): > wrap = Person > > ps = PersonSchema() > form_defaults = ps.from_python(None) > new_object = ps.to_python(form_input) > form_defaults = ps.from_python(aPerson) > edited_person = ps.to_python(edited_form_input) > """ > > -- > Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
