SQLAlchemy == 1.0.3
mysql-python == 1.2.5
I have been playing around with baked queries and have a couple
observations, one which is problem my lack of SQLA knowledge and the other
a possible feature.
1) .in_ and bindparam
I have a query that I am baking that uses in_ with a python list. For
You're right, of course. Adding has_type() to OracleDialect is more a matter of
taste than a necessity.
Thanks again for all your help. I'm actually amazed at how well/transparent it
works, given the cx_Oracle limitations.
_
From: Mike Bayer
On 10/03/2016 05:21 PM, Seth P wrote:
On Friday, September 30, 2016 at 7:09:09 PM UTC-4, Mike Bayer wrote:
the bind_expression() hook is here to allow you to re-render the
expression. assuming value-bound bindparam() objects (e.g. not like
you'd get with an INSERT or UPDATE
On Friday, September 30, 2016 at 7:09:09 PM UTC-4, Mike Bayer wrote:
>
> the bind_expression() hook is here to allow you to re-render the
> expression. assuming value-bound bindparam() objects (e.g. not like
> you'd get with an INSERT or UPDATE usually), the value should be present
> and you
Hi Mike,
Thanks. If I read you correctly, I have 2 options:
1.) autogenerate --> proof-read migration script --> manually add the views
to upgrade() and downgrade()
2.) Write custom extensions and invoke them in env.py --> autogenerate -->
proof-read migration script
Say I want to explore
On Mon, Oct 3, 2016 at 11:43 AM, Jinghui Niu wrote:
> This really helps. Thank you Simon! I still have a couple of smaller
> questions.
>
>> When you access .fullname, the "self" parameter is now the
>> *class*, so self.firstname and self.lastname are SQLAlchemy column
>>
This really helps. Thank you Simon! I still have a couple of smaller
questions.
When you access .fullname, the "self" parameter is now the
> *class*, so self.firstname and self.lastname are SQLAlchemy column
> properties.
Here by *column properties* do you mean the object returned by
The first example from the docs is illustrating the most simple case,
where the function happens to work at both the instance and class
level. Here's the example:
class User(Base):
__tablename__ = 'user'
id = Column(Integer, primary_key=True)
firstname = Column(String(50))
>
> User.firstname is not the value from any particular row - it's the
> (ORM-level) column object.
It's a little abstruse here that a ORM-level instrumented column object,
such as User.firstname works, but a true Column object, such as
User.__table__.c.firstname doesn't. Maybe I misunderstood
Thank you Simon. Your explanation helps me understand this quite a lot.
Sometimes the documentation is so terse that only when you fully understand
the subject then you can understand it by reading it:) But still if I want
to implement this hybrid property from the query level, how would you
On Mon, Oct 3, 2016 at 7:17 AM, Jinghui Niu wrote:
> I have a ledger table and a corresponding python class. I defined the model
> using SQLAlchemy, as follows,
>
> class Ledger(Base):
> __tablename__ = 'ledger'
>
> currency_exchange_rate_lookup = {('CNY', 'CAD'):
I have a ledger table and a corresponding python class. I defined the model
using SQLAlchemy, as follows,
class Ledger(Base):
__tablename__ = 'ledger'
currency_exchange_rate_lookup = {('CNY', 'CAD'): 0.2}
amount = Column(Numeric(10, 2), nullable=False)
currency =
12 matches
Mail list logo