Ben,
I think I might have seen you write in IRC that you had already
decided not to autoreflect after all, not sure if this is the same
person. But in any case, I wanted to say that one good reason NOT to
autoreflect is as follows. If you do the work of building a
declarative model for your
well yeah like I said I think you need to subclass Query first off, then
intercept your special entities in the constructor and do special processing in
__iter__.
On Jun 6, 2012, at 5:55 PM, Victor Olex wrote:
To be clear this is not a feature request. I could use a hit how to
build a fake
Fantastic, that event hack was just what I needed. I did have to change
sub to replace on the statement, for any future readers, but that was a
trivial change. Thanks Michael!
Shawn
On Wednesday, June 6, 2012 3:51:55 PM UTC-4, Shawn Wheatley wrote:
Hi,
I'm trying to use my declarative
No, that wasn't me!
I actually have a couple of demo projects I am going to use SqlAlchemy on. One
of them a third party has already gone and created a mysql database.In
this case it's like 7 tables, so no big deal. But other projects with pre
existing DBs have 100 tables.
I have
Question:
Generally, How does one tell SQLAlchemy that a table is read-only (via
DB permissions) so it doesn't try to do things to it that table
implicitly that require more then select permission?
Or asked another way, How does one tell SQLAlchemy that a first table
(say States) is read only
On Jun 7, 2012, at 5:59 PM, Ryan D wrote:
Question:
Generally, How does one tell SQLAlchemy that a table is read-only (via
DB permissions) so it doesn't try to do things to it that table
implicitly that require more then select permission?
SQLAlchemy does not do INSERT/UPDATE/DELETE
