On Apr 20, 2012, at 6:52 PM, Jeff Dairiki wrote:
> On Fri, Apr 20, 2012 at 03:44:55PM -0400, Michael Bayer wrote:
>>
>> The one thing that's needed as far as Alembic is concerned is the
>> ability to control the name of the actual "migration" table per
>> environment, this is a short feature add
On Fri, Apr 20, 2012 at 03:44:55PM -0400, Michael Bayer wrote:
>
> The one thing that's needed as far as Alembic is concerned is the
> ability to control the name of the actual "migration" table per
> environment, this is a short feature add that's been sitting as an
> enhancement request for some
On Fri, Apr 20, 2012 at 9:28 PM, Michael Bayer wrote:
>
> On Apr 20, 2012, at 8:45 AM, Eric Lemoine wrote:
>
>> On Mon, Apr 16, 2012 at 10:49 PM, Eric Lemoine
>> wrote:
>>> Hi
>>>
>>> I'd like to use an associationproxy for a simple many-to-one relationship:
>>>
>>> class Child(Base):
>>> __t
On Apr 20, 2012, at 4:52 AM, Wichert Akkerman wrote:
>
> That suggests that every package would have its own migration tool, which is
> not very practical from a sysadmin point of view. I am an upgrading an
> application I want to be able to run all necessary migrations for all
> components o
On Apr 20, 2012, at 9:32 AM, Julien Cigar wrote:
> Hello,
>
> I'm using joined load inheritance in one of my project, and I have the
> following query:
>
> q = Content.query.outerjoin((File, File.content_id == Content.id), File.mime,
> Mime.major)
>
> SQLAlchemy generates a subquery for the
On Apr 20, 2012, at 8:51 AM, lars van gemerden wrote:
> Ok, thank you, that helps, but now i cannot inherit from Engineer, as in:
>
> class BaseMixin(object):
>
> discriminator = Column(String(50))
>
> @declared_attr
> def __tablename__(cls):
> return cls.__name__
> @de
On Apr 20, 2012, at 8:45 AM, Eric Lemoine wrote:
> On Mon, Apr 16, 2012 at 10:49 PM, Eric Lemoine
> wrote:
>> Hi
>>
>> I'd like to use an associationproxy for a simple many-to-one relationship:
>>
>> class Child(Base):
>> __tablename__ = 'child'
>> id = Column(Integer, primary_key=True
On 19/04/2012 18:43, Michael Bayer wrote:
but with the possibility of dependencies between those tables. If I
understand correctly, if we were dealing with sets of tables that didn't
have any dependency, you wouldn't need a distributed migration tool,
each package would handle migrations for its
Hello,
I'm using joined load inheritance in one of my project, and I have the
following query:
q = Content.query.outerjoin((File, File.content_id == Content.id),
File.mime, Mime.major)
SQLAlchemy generates a subquery for the outer join.
Any idea how to ask SQLAlchemy to generate a shorter F
Hi Mike,
How about this approach with a custom metaclass; so far it works and seems
the cleanest to me:
from sqlalchemy import *
from sqlalchemy.orm.session import sessionmaker
from sqlalchemy.ext.declarative import declarative_base,
has_inherited_table, DeclarativeMeta
engine = create_engine(
Ok, thank you, that helps, but now i cannot inherit from Engineer, as in:
class BaseMixin(object):
discriminator = Column(String(50))
@declared_attr
def __tablename__(cls):
return cls.__name__
@declared_attr
def id(cls):
return Column(Integer, primary_key = Tr
On Mon, Apr 16, 2012 at 10:49 PM, Eric Lemoine
wrote:
> Hi
>
> I'd like to use an associationproxy for a simple many-to-one relationship:
>
> class Child(Base):
> __tablename__ = 'child'
> id = Column(Integer, primary_key=True)
> name = Column(Unicode)
>
> class Parent(Base):
> __t
Michael,
On 20/04/2012 12:21, Michael Bayer wrote:
On Apr 20, 2012, at 4:51 AM, Werner wrote:
On 20/04/2012 10:36, Werner wrote:
I use Firebird SQL, and "like" has a pretty bad performance compared to "starting
with", as the later uses an index if one is available.
When using "someklass.som
there's other edges too, like a custom Column subclass, and contents within the
open-ended info dict, so __conflicts__ keeps this simple.
I've added ticket 2472 for this.
On Apr 19, 2012, at 4:31 PM, Amos wrote:
> It would be great for declarative to resolve a conflict (perhaps with
> a warnin
On Apr 20, 2012, at 4:59 AM, lars van gemerden wrote:
> this is the testcase:
>
>
> What am i missing?
the issue here is one of Python inheritance mechanics. Declarative calls upon
@declared_attr in terms of the class, that is, we look through the class to
find each @declared_attr, but wh
On Apr 20, 2012, at 4:51 AM, Werner wrote:
> On 20/04/2012 10:36, Werner wrote:
>> I use Firebird SQL, and "like" has a pretty bad performance compared to
>> "starting with", as the later uses an index if one is available.
>>
>> When using "someklass.somecolumn.startswith('value') SA uses "like
this is the testcase:
from sqlalchemy import *
from sqlalchemy.orm.session import sessionmaker
from sqlalchemy.ext.declarative import declarative_base, declared_attr
engine = create_engine('sqlite:///:memory:', echo=False)
Base = declarative_base(bind = engine)
Session = sessionmaker(bind = engin
On 04/19/2012 07:43 PM, Michael Bayer wrote:
If you've seen my recent talks you saw that I'm a little skeptical of
what you're terming "non-monolithic" databases.Let's say this
means, a database with a set of tables maintained by entirely
different packages, but with the possibility of depe
On 20/04/2012 10:36, Werner wrote:
I use Firebird SQL, and "like" has a pretty bad performance compared
to "starting with", as the later uses an index if one is available.
When using "someklass.somecolumn.startswith('value') SA uses "like",
what would have to be done to use "starting with" ins
I use Firebird SQL, and "like" has a pretty bad performance compared to
"starting with", as the later uses an index if one is available.
When using "someklass.somecolumn.startswith('value') SA uses "like",
what would have to be done to use "starting with" instead for the
Firebird dialect?
We
20 matches
Mail list logo
