hey Michael - made some progress with this. the program you attached is perfectly fine and is the kind of thing i would want to see people do. I would think that if you just wanted a mapper that maps to only a subset of the columns in a table, there might be some other options to mapper for that, but creating a select around just the columns that you want is an interesting take on it. I had to adjust Mapper to be a little more liberal about attributes not being defined, when matching underlying non primary-key table columns to object attributes. if you check out SVN version 1195 you will get this behavior. also updated objectstore logging to work again which had broken.
also attached is test.py, which is the program you gave me but without the
MapperExtension...for what youre doing, you dont need a mapper extension
or any polymorphic mapping to work with those two objects. if you want to
make a third mapper which does the polymorphic thing, then you could do
that. I would create that mapper against a "dummy" class. of course i
havent tried any of that so there might be issues. I also had Test1 and
Test2 create with 'data1' and 'data2' as the attribute names, not sure if
you were trying to translate those names in but i would do that either
within your select or as column properties:
assign_mapper(Test1, test1select, properties ={
'data':test1select.c.data1
})
finally, I created a variant on the polymorph example which is checked in
as examples/polymorph/polymorph2.py, and uses some new stuff I just
checked in last night. this is going for a more "two totally different
objects" approach and ive worked out a way for one mapper to use a second
mapper for the entire "attribute population" process.
While the "polymorph" thing is kind of an exotic novelty, it looks like im
almost coming up to just some standard function that would do this all
automatically...but theres some complexity with result-row column
translation that gets tricky, needs more looking into. i would sort of
prefer "polymorphic mapping" to be a "cookbook" type of thing anyway
rather than yet another keyword argument to mapper...
Michael Carter wrote:
> Thanks for the quick reply.
>
> The example is helpful but, as you mentioned, it doesn't get us to the
> case
> where we can have two (or more) subclasses with large sets of different
> attributes.
>
> Its true that the method you use in the polymorphic example is basically
> filtered mapping. I think it would perform better with a single table
> though
> even if it were more messy. I wasn't too clear in what I was trying to do
> with mapping against selects, and I suspect that I may be way off course
> in
> how the technique can be used, but I am attaching an example.py and an
> example_tb.err file with the traceback from the error that occurs when I
> run
> it. Basically I have one table called tests, and then two classes Test1
> and
> Test2. An instance of a Test1 should only have a way to load and save
> from/to the column data1 while Test2 should only be able to load/save from
> the column data2. A good default behavior would be to leave those columns
> as
> None or Null. If this could work then it wouldn't be too hard to create
> complex inheritance structures in a single table, and it'd have the added
> benefit of being very easy to reference a set of different types in the
> same
> inheritance tree via some relation.
>
> Let me know if this makes any sense, or if I should stop trying to pursue
> a
> solution along these lines.
>
> Thanks,
> Michael
>
test.py
Description: Binary data
