On 4/27/07, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
> On Apr 27, 2007, at 2:19 PM, Mike Orr wrote:
>
> > Is it possible to make a mapper class that loads & modifies only some
> > fields in a table rather than all the fields, yet still autoloads the
> > fields rather than having hardcoded column types?
>
> you want to use a "deferred" column :
>
> http://www.sqlalchemy.org/docs/
> adv_datamapping.html#advdatamapping_properties_deferred
That puts the burden in the wrong place: (1) I have to list all the
undesired columns by name, (2) SQLAlchemy has to go to the trouble of
making it a deferred column when I'd prefer it just ignore it
entirely.
> yeah when you map to a select, it treats that like "a table", and
> selects from it so that it can be manipulated similarly.
Is it safe to do updates on an object mapped to a select? E.g.,
_sel = select([... fields ...])
class Foo(object): pass
mapper(Foo, _sel)
for i in session.query(Foo).select():
i.attr = "Value"
session.flush()
> > What I'd like to do is pass a list of column names to the Table
> > constructor and have it autoload those and ignore the others. I
> > couldn't find an argument for this.
>
> oh. well that we haven't done yet. the usual use case is that if
> you know the names of the columns already, why reflect them ? but
> yes i understand the advantage of getting the data types and foreign
> key constraints reflected. this wouldnt be a difficult feature to add.
Created ticket #561 suggesting:
Table("Foo", meta, autoload_columns=["foo_id", "col2", "col3"])
> > - Is there a supported way to add/remove fields from a query after
> > it's been constructed?
>
> from a select(), it supports adding things. there is append_column
> (), append_whereclause(), order_by(), etc. this API needs docstrings
> and probably the names "order_by/group_by" should be named
> "append_order_by()" etc. but you can see the methods listed out in
> the HTML docstrings on the site (html docs also included with the dist).
>
> removing things is not stressed so much since the typical use case is
> "building up" a query from a core criterion/selectable, and we have
> the usual issue about decisions being made based on things being
> appended, which to support removal would mean a lot of new code
> (which id welcome, of course !) to support "un-making" those decisions.
.append_column just needs to be documented in the manual.
.remove_column would be useful, but it's not that important if it's
complicated to implement. (I thought the column list was just a
simple list until the query was compiled.) I wasn't suggesting
.remove_whereclause or .remove_order_by -- I don't see any point for
those, and how would one identify the element to remove anyway?
--
Mike Orr <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
