Thanks. I followed your suggestion and defined my columns for that table
manually, and it works.
On Wednesday, December 28, 2016 at 8:14:14 AM UTC-8, Mike Bayer wrote:
>
> MySQL reflection depends on DESCRIBE being available so if that's not
> possible you'd have to forego having these tables be
On 12/27/2016 04:36 PM, Tucker Beck wrote:
Mike (or whoever else might have insight):
I used the pattern above, and it worked great until I tried use it for a
really large table that I was querying and filtering by the hybrid
property. Something like this:
query(HybridModel).filter_by(hybrid_t
Another update on this issue. It seems that the issue stems from having a
declared_attr for the __tablename__. If I remove that and make it a static
class attribute, things work as expected.
On Tue, Dec 27, 2016 at 1:36 PM, Tucker Beck wrote:
> Mike (or whoever else might have insight):
>
> I us
MySQL reflection depends on DESCRIBE being available so if that's not
possible you'd have to forego having these tables be reflected, instead
you'd have to code the columns you care about in the application.
On Dec 25, 2016 3:55 AM, "Ben Mishkanian" wrote:
> Hello,
>
> I am having an issue simi
Calling session.delete() is equivalent to calling session.add() first.
The only downside is if the object represents state that has changed in the
database elsewhere, like the row was already deleted or had a primary key
change.
On Dec 28, 2016 8:18 AM, "Julio César Gázquez" <
julio_li...@mebamut
Hi list.
I just noticed that if I retrieve an object, and close the session
letting the object in detached state, then I can delete the object from
the database using a new session simply issuing session.delete(),
without merging it first. SQL Alchemy simply emits the DELETE and that's
it, av
