On Wed, 2010-07-07 at 18:45 -0400, Michael Bayer wrote:
> On Jul 7, 2010, at 6:30 PM, Lance Edgar wrote:
>
> > On Jul 7, 2:01 pm, Michael Bayer <mike...@zzzcomputing.com> wrote:
> >> On Jul 7, 2010, at 1:53 PM, Lance Edgar wrote:
> >>
> >>
> >>
> >>> OMichael, thanks for the tip. I still found this somewhat confusing
> >>> though:
> >>
> >>> When my code runs, the mapper has already been created (and
> >>> "compiled", I assume). So what I ended up doing, that seemed to work,
> >>> is:
> >>
> >>> class_mapper(Order).add_property('quantity',
> >>> column_property(cast(orders.c.quantity, Integer)))
> >>
> >>> The thing is, the mapper *already* had a "quantity" property so
> >>> without knowing the internals of that business I can only assume that
> >>> my .add_property() call doesn't have weird side effects (although it
> >>> does accomplish what I'm after). The mapper exposes .get_property()
> >>> and .iterate_properties(), and of course .add_property(), but I guess
> >>> I would have expected there to be a .set_property()
> >>> or .update_property(). Is this just a quirk in the wording or my
> >>> understanding, or am I still missing some important step?
> >>
> >> It's add_property() since you are adding a new property to the existing
> >> collection of properties. It is not really intended for the
> >> "replacement" of existing properties as that has direct impact on the
> >> instrumentation of the mapped class. It probably works in the simple
> >> case here, but would be better if you were to define it "inline" with the
> >> original Order mapper.
> >
> > Well, I'm already seeing some issue(s) with it even in my simple
> > case. Where this used to return an Integer-type Column...
> >
> > class_mapper(Order).get_property('quantity').columns[0]
> >
> > ...now it returns a sqlalchemy.sql.expression._Label object. This
> > makes sense because of the "SELECT CAST(...) AS anon_1" that's
> > happening at the SQL level, but it's throwing FormAlchemy off in this
> > case and I guess generally speaking I hoped for a more transparent
> > override. So my follow-up question is: Is there a way to tear down
> > and replace the mapper for just a single class, or is the only
> > relevant option the clear_mappers() function which will remove all
> > class mappings? If I can't replace a single property within the
> > mapper then I'm ok with replacing the mapper, but replacing all of
> > them seems a bit heavy-handed.
>
> No, you have to set up the mappers the way you want them to be the first time
> around. If FormAlchemy is setting up mappers for you without you being able
> to change how it does that, then they should fix that.
Hm, okay then. FWIW, FormAlchemy isn't creating any mappers, but it
must be examining the properties found in them. If I don't override the
mapper's "quantity" property then FA will render the field as being a
writable decimal. If I do override it then FA renders it as a read-only
integer (I'm assuming this is because of the _Label being found there in
place of the Column). I need it to be a writable integer. So it sounds
like telling the ORM to cast it to an integer as part of the original
mapper definition is the "ideal" solution, but the project structure is
such that the mappers are created elsewhere (different project) and the
classes are imported from there.
I think I'll just fiddle with the FA rendering so as to emulate an
integer type in the UI; that was the next thing to try anyway. Thanks
again.
Lance
--
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.
