On Oct 17, 1:36 am, Michael Bayer wrote:
> At the moment you have an and_() of two string expressions, which
> SQLalchemy knows nothing about and therefore cannot apply mapping
> logic to it. When using declarative, you do have the option to quote
> the expression in the case that you'd
On Oct 17, 2009, at 1:07 AM, cd34 wrote:
>
> When I add the second condition in the primaryjoin as:
>
>users = relation('cp_users', primaryjoin=and_
> ('cp_package_device.device_id
> =
> =
> cp_users.device_id
> ','cp_package_device.client_id==cp_users.client_id'),foreign_keys=
> ['cp_users.
I'm using SQLAlchemy 0.5.6, Python 2.5.4, Debian Linux
I have a defined schema but am experimenting with a different way to
display the data. While I have gotten a portion of this working, I am
stuck putting the second condition into the primaryjoin. Classes have
been clipped for brevity.
clas
On Oct 15, 11:50 pm, Jeff Cook wrote:
>
> So, SQLAlchemy is doing something here. There probably is some
> incorrect code in my program, which is why I am writing this list, to
> figure out what that is. I'm an experienced developer and I don't
> appreciate your disrespect. I can follow tutorials
Thanks for the help. I wasn't assigning the session to SQLSoup's
session, but I am now, and I'm still getting stale data and I don't
know yet if I'll still be getting the invalid transaction/MySQL has
gone away thing. I think I'll try just taking SQLSoup out of the thing
all together and try SQLAl
I'm sure this is something fairly basic, but I'm stumped at this
point. I have a single table inheritance scheme setup very similar to
this:
class SimpleType(object):
def __init__(self, type='base_type', name='base_type'):
self.type = type
self.name = name
class AddressType(S
I'm trying to setup fast insertions using sqlalchemy/sqlite and it
seems to be taking an unnecessarily long amount of time to do many of
the inserts.
It looks like the main call that inserts into a few tables takes about
1-2 seconds each for the first few calls, but then drops down to
around 50ms
On Oct 16, 5:18 pm, "Michael Bayer" wrote:
> fogathm...@googlemail.com wrote:
>
> > Ah, thanks, that makes sense. So I was wrong in assuming the two forms
> > were equivalent - backref merely allows you to access a relation from
> > the other side, whereas back_populates performs synchronizatio
fogathm...@googlemail.com wrote:
>
> Ah, thanks, that makes sense. So I was wrong in assuming the two forms
> were equivalent - backref merely allows you to access a relation from
> the other side, whereas back_populates performs synchronization on
> both ends. OK, I will keep that in mind from no
On Oct 16, 12:50 pm, Michael Bayer wrote:
> On Oct 16, 2009, at 4:43 AM, fogathm...@googlemail.com wrote:
>
>
>
>
>
> > Hello!
>
> > From reading the docs, I assumed that using "backref" on the child's
> > orm.relation declaration in a 1:n relationship is equivalent to using
> > "back_populates
Hi Gaetan,
On Oct 14, 5:11 pm, Gaetan de Menten wrote:
> On Wed, Oct 14, 2009 at 17:09, Gaetan de Menten wrote:
>
> > Btw: Iwan, did you try:
>
> factory = elixir.session.session_factory
> elixir.session.registry = sqlalchemy.util.ScopedRegistry(factory,
> scope_func=your_scope_func)
I gave up
Hi,
I think it would be cool to have an option to obtain the results of a
sqlalchemy query as a numpy's recarray, instead of a list of tuples as
it is now.
Examples:
>>> data = session.query(People.name, People.surname, People.apples,
>>> People.pears).as_recarray()
>>> data['name']
Albert
Mari
On Oct 16, 2009, at 4:43 AM, fogathm...@googlemail.com wrote:
>
> Hello!
>
> From reading the docs, I assumed that using "backref" on the child's
> orm.relation declaration in a 1:n relationship is equivalent to using
> "back_populates" with explicit orm.relation declarations on both ends.
> How
On Oct 15, 2009, at 11:50 PM, Jeff Cook wrote:
>
> So, SQLAlchemy is doing something here. There probably is some
> incorrect code in my program, which is why I am writing this list, to
> figure out what that is. I'm an experienced developer and I don't
> appreciate your disrespect. I can follow
I should probably ask something else too… how much overhead is there
in
using subtransactions as opposed to one "global" transaction?
On Oct 14, 3:18 pm, "Michael Bayer" wrote:
> Oliver Beattie wrote:
>
> > Hi All,
>
> > I'm just wondering what happens if I were to call session.close()
> > whils
Thanks for your quick answer, Michael, that's really helpful.
Sorry for the confusion surrounding subtransactions vs. SAVEPOINTs —
I am indeed using subtransactions… just clearly haven't got the lingo
down yet ;)
Looking at my code now, I'm not too sure why I felt the need to call
close() at all
Hello!
>From reading the docs, I assumed that using "backref" on the child's
orm.relation declaration in a 1:n relationship is equivalent to using
"back_populates" with explicit orm.relation declarations on both ends.
However, it turns out that I get double insertions when using
back_populates -
17 matches
Mail list logo
