Re: [sqlalchemy] Handle anticipated data truncation before transaction commits

On Friday, November 3, 2017 at 12:03:43 AM UTC-4, jens.t...@gmail.com wrote: > > Thanks Mike! Considering we're planning to migrate to PostgreSQL in a > month or two, how would I go about that (considering there's no strict mode > there). Would the exception be raised on PostgreSQL? > A

Re: [sqlalchemy] Handle anticipated data truncation before transaction commits

Hm. I enabled strict mode, and sure enough the warning turns into an exception. Alas, it seems that the flush() in the above example does not cause the exception, it happens later when the query executes. I was looking for a way to preempt that exception: the code runs within a view function

Re: [sqlalchemy] Handle anticipated data truncation before transaction commits

Thanks Mike! Considering we're planning to migrate to PostgreSQL in a month or two, how would I go about that (considering there's no strict mode there). Would the exception be raised on PostgreSQL? Jens On Friday, November 3, 2017 at 12:04:54 PM UTC+10, Mike Bayer wrote: > > > What is the

Re: [sqlalchemy] Handle anticipated data truncation before transaction commits

On Thu, Nov 2, 2017 at 9:27 PM, wrote: > Hi, > > I've got a db object with a string property that may grow larger than its > column specifies (because it's being appended to). I tried: > > old_string = obj.string > try: > obj.string = "abc" * 1 >

[sqlalchemy] Handle anticipated data truncation before transaction commits

Hi, I've got a db object with a string property that may grow larger than its column specifies (because it's being appended to). I tried: old_string = obj.string try: obj.string = "abc"

Re: [sqlalchemy] Declarative API without state management

On Thu, Nov 2, 2017 at 3:09 PM, Max Rothman wrote: > I was poking around Elixir's Ecto, and I was curious whether it was possible > to apply their strict separation between data and operations to SQLAlchemy. > One could imagine an API where session.query fetches mutable,

[sqlalchemy] Declarative API without state management

I was poking around Elixir's Ecto , and I was curious whether it was possible to apply their strict separation between data and operations to SQLAlchemy. One could imagine an API where session.query fetches mutable, data-only versions of models, and models are

Re: [sqlalchemy] Possible inconsistency between schema names and FKs when inspecting SQLite

I ran your code and worked perfectly, I was using "sqlite+pysqlite" instead of "sqlite" as the engine but the behavior remains the same. Examining the example I discovered the inspector was correctly retrieving the foreign keys using 'main' as a schema but filtering them out later, sorry for