Re: [sqlalchemy] Grouped data in a Flask/SQLAlchemy class

Hi Mike, I'm finally getting to this. Instead of having both a detail and grouped methods, I would like to have only the grouped method. I'm not sure I follow your suggestion for the two methods above and how that would be modified to fit into the @property in my class. Could you please

[sqlalchemy] .one is not returning a KeyedTuple, but a

We are upgrading from 0.9.7 to 1.1.9 and I've run into a bit of a problem with the upgrade. I have a query which is based on a .select_from() and .join() so the mapping doesn't really exist from a single model. All of the fields have labels though and the result set produces the right

Re: [sqlalchemy] .one is not returning a KeyedTuple, but a

On 04/24/2017 12:44 PM, Mark Jones wrote: We are upgrading from 0.9.7 to 1.1.9 and I've run into a bit of a problem with the upgrade. I have a query which is based on a .select_from() and .join() so the mapping doesn't really exist from a single model. All of the fields have labels

Re: [sqlalchemy] Grouped data in a Flask/SQLAlchemy class

On 04/24/2017 12:51 PM, Greg Silverman wrote: Hi Mike, I'm finally getting to this. Instead of having both a detail and grouped methods, I would like to have only the grouped method. I'm not sure I follow your suggestion for the two methods above and how that would be modified to fit into

Re: [sqlalchemy] Grouped data in a Flask/SQLAlchemy class

My naive first response would be that I want the class to look like class DiagnosisTest(Model): __tablename__ = 'vw_svc_diagnosis' #id = Column(Integer, primary_key=True, autoincrement=True) dx_id = Column(String(32), primary_key=True) first_name = Column(String(255))

Re: [sqlalchemy] Grouped data in a Flask/SQLAlchemy class

On 04/24/2017 03:42 PM, Greg Silverman wrote: My naive first response would be that I want the class to look like class DiagnosisTest(Model): __tablename__= 'vw_svc_diagnosis' #id = Column(Integer, primary_key=True, autoincrement=True) dx_id= Column(String(32),primary_key=True)

Re: [sqlalchemy] eager loading relationships after an initial query?

yeah just load the object again w/ the eagerloads option you want. On 04/24/2017 04:12 PM, Jonathan Vanasco wrote: [I couldn't find any docs on this, and my luck with the list archives only showed some potential work for this in 2008.] Is it currently possible to eager-load a ORM relationship

Re: [sqlalchemy] eager loading relationships after an initial query?

On Monday, April 24, 2017 at 4:28:22 PM UTC-4, Mike Bayer wrote: > > yeah just load the object again w/ the eagerloads option you want. > Thanks. I was hoping there was a way to just say `Obj.load('foo')` ? I'll just untangle the code and load the relationship in the first place. At this

[sqlalchemy] eager loading relationships after an initial query?

[I couldn't find any docs on this, and my luck with the list archives only showed some potential work for this in 2008.] Is it currently possible to eager-load a ORM relationship after a query? For example, I have loaded an instance of `Foo`, but I did not do an eager load on `Foo.bars` and

Re: [sqlalchemy] autogenerate migrations with alembic for inherited tables

пятница, 21 апреля 2017 г., 17:07:34 UTC+3 пользователь Mike Bayer написал: > > > > On 04/21/2017 09:16 AM, Антонио Антуан wrote: > > Helllo. > > I have a model, with specified __tablename__ = 'base_table'. > > In postgresql, the table has trigger, which executes before each insert: > > it

Re: [sqlalchemy] autogenerate migrations with alembic for inherited tables

On 04/24/2017 07:21 AM, Антонио Антуан wrote: Here is definition. PostgreSQL ensures that all columns that are in "table_master" will be in the inherited tables, but the indexes won't: I should create them manually by describing it in procedure code. So, if I add new index, I should add

Re: [sqlalchemy] Grouped data in a Flask/SQLAlchemy class

Yes, I can certainly do that. Sounds pretty simple, actually. I may have more questions as I dive into this. Thanks! On Mon, Apr 24, 2017 at 3:06 PM, mike bayer wrote: > > > On 04/24/2017 03:42 PM, Greg Silverman wrote: > >> My naive first response would be that I