mapper.select_mapper()

[Former user]

when one does a mapper.select() objects of the mapper.class_ are returned, based on the output of mapper.table.select().

now the results of the table.select() is a selectable/view, and can be used in any context that accepts a selectable, including the binding of a mapper.

these two observations in combination seem to indicate that it is possible for there to be a mapper.select_mapper() method which returns a new mapper which is a clone of the original mapper, except that it is bound to the new selectable based on the arguments instead of the original mapper's table.

[Mike Bayer]

there are some internal complexities to this which I have begun to address, namely that mappers try to cache themselves when created, and ive had to work on the mechanics of select() objects reporting their "identity" appropriately so that creating the same mapper() from an equivalent but different-identity select() over and over again doesnt produce new mappers each time, eating up memory in the process.

the typical way to make a "copy" of a mapper is through the "options" method, so if we went this way it would look like:

m = mapper.options(select_mapper(table.c.col1==6))

or the "by" version:

m = mapper.options(select_mapper_by(col1=5, col2=7))

but thats kind of clunky and also doesnt correspond well with how "options" works, which makes the copy first, then applies the options. in this case we want to make a completely different mapper from a new selectable, then copy the properties. although can we really copy the properties ? hmm. gets a little weird.

so the other way looks like:

m = mapper.adapt(table.c.col1==6)
m = mapper.adapt_by(col1=2, col2=6)

which is shorthand for:

statement = mapper._compile(table.c.col1==6)
m = mapper(statement)

but then all the properties on the original mapper, im not totally sure how to transfer those over. ill see if i can post some comments on how weird that might get (like how do we convert custom join conditions from table1->table2, into a selectable->table2 ? ill have to see how that works out. is there a particular use case you have in mind for this feature ?)

[Mike Bayer]

this is ancient and is all addressed by Query.select_from() and similar these days.