I guess it depends how you look at it. To me assign_mapper adds some
Query methods and not others; e.g., .select and .count but not .filter
. I assume that's because .filter is so new. But in the manual under
Generative Query Methods it implies that .select and .filter are
parallel; i.e., you
johnbraduk Using SQLAlchemy-0.3.7-py2.4 released with Turbogears
johnbraduk Traceback (most recent call last): File
johnbraduk /var/tmp/sqlatest.py, line 3, in -toplevel- fbdb =
johnbraduk create_engine(dbstr) File
johnbraduk
@Michael Bayer
Thank you.
The issue could not be solved, probably due to database restrictions
(e.g. allowing stored procedures to be used only by admin rights, even
though SQLAlchemy used an admin type user...seems that the database
server recognizes that the call is being made from an external
Michael,
Here are the results I am getting. I am trying to get TurboGears to
work so I don't know which versions of SQLAlchemy can be used with TG
and not screw it up.
Test prog.
from sqlalchemy import *
dbstr = 'firebird://SYSDBA:[EMAIL PROTECTED]/usr/ibdata/eiti61.gdb'
fbdb =
FYI I get this trace with the version you attached.
Traceback (most recent call last):
File /home/john/sqla/sqlatest.py, line 5, in -toplevel-
fbdb = create_engine(dbstr)
File build/bdist.linux-i686/egg/sqlalchemy/engine/__init__.py,
line 154, in create_engine
File
as it turns out, assign_mapper's monkeypatched methods (and they are
all monkeypatched, not sure why you singled out query()) dont conflict
with mapped properties since those properties get set up subsequent to
the assign_mapper call and replace them. however adding new methods
to assign_mapper
Patch applied now and wokr like is expected.
Thanks
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this
On Fri, Jun 01, 2007 at 07:17:19AM -0700, Michael Bayer wrote:
so i didnt add filter() because i didnt feel like getting all the bug
reports from people who have instance variables called filter, and
also because my plan was to do away with *all* the select/filter/etc
methods and have
the latest version of MySQLDB does use weakrefs right at the heart of
things, in connections.py and cursors.py.since we are catching the
exception we cant see the full original stack trace but its possible
that it would trace into mysqldb's source code.
that doesnt rule out that we are doing
For what it's worth I personally vote to get rid of all those query
methods (except query() itself, of course).
On 6/1/07, Michael Bayer [EMAIL PROTECTED] wrote:
as it turns out, assign_mapper's monkeypatched methods (and they are
all monkeypatched, not sure why you singled out query()) dont
What is the best way for create a clone of Select object except for
columns list ?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
On Jun 1, 11:37 am, Christoph Haas [EMAIL PROTECTED] wrote:
sooner or later. Am I right that we are just talking of
john = session.query(User).get_by(name=john)
versus
john = User.get_by(name=john)
well assign_mapper gives you the *huge* advantage that you can forget
about the
Hello
I am seeing an error when trying to insert a row with a date field
into an SQLite database. The error is the same as the problem that has
been seen with Decimals on postgres but presumably it's a different
issue. I have upgraded my pysqlite to 3.3.17 but that didn't help.
Below is the
On 6/1/07, Michael Bayer [EMAIL PROTECTED] wrote:
On Jun 1, 11:37 am, Christoph Haas [EMAIL PROTECTED] wrote:
sooner or later. Am I right that we are just talking of
john = session.query(User).get_by(name=john)
versus
john = User.get_by(name=john)
well assign_mapper
youll notice from this:
sqlalchemy.exceptions.SQLError: (InterfaceError) Error binding
parameter 1 - probably unsupported type. u'INSERT INTO things (date,
value) VALUES (?,?)' ['(datetime.date(2007, 6, 1),)', ('asdf',)]
both the date and the 'asdf' values are being sent in the form of one-
On Jun 1, 2007, at 12:39 PM, Gaetan de Menten wrote:
This enables things like so (see attached elixir-based example for
more):
A.query().filter_by_via('b', name='b2').filter_by_via('c',
name='c2')
To Michael: I'm ready to document that myself, but I just don't want
to do it for
On Jun 1, 2007, at 12:46 PM, Gaetan de Menten wrote:
To get this straight, this was my personal opinion, not the one from
the whole elixir crew. The other option which was discussed was to
get rid of assignmapper altogether (in favor of defining the methods
on our base class so that people
Both
session.query(User).select()
and
User.query().select()
seem more verbose than they need to be for my taste. However, I think most
people (myself included) define a base class for all their mapped classes.
I've always used this base class to provide the interface I want, no matter
what
On Fri, Jun 01, 2007 at 10:50:33AM -0700, David Shoemaker wrote:
Both
session.query(User).select()
and
User.query().select()
seem more verbose than they need to be for my taste. However, I think most
people (myself included) define a base class for all their mapped classes.
Uhm,
On 6/1/07, Michael Bayer [EMAIL PROTECTED] wrote:
the latest version of MySQLDB does use weakrefs right at the heart of
things, in connections.py and cursors.py.since we are catching the
exception we cant see the full original stack trace but its possible
that it would trace into
On Jun 1, 2007, at 1:24 PM, Michael Bayer wrote:
and we can even bring back a modified version auto-descend in that
case:
query(A).filter_by(C, lala=5)
since above its not ambiguous.
actually, scratch that. C can be related to multiple times. also
its ambigious if you want autojoin
On Jun 1, 2007, at 2:23 PM, Mike Orr wrote:
Why can't SQLAlchemy catch this and the gone-away error, refresh the
connection, and redo the query like SQLObject does? That's really
what one wants, not a pool_recycle time. I think you said that's
incompatible with transactions but I don't
OK, irc continues, now i see what youre getting at, its this:
query.filter_by(['a', 'b', 'c'], foo=bar)
query.filter_by('c', foo=bar)
i didnt pick up on the list part from the example.
that feature specifically starts to look like a django join. the
'join list' at the front is contained
I used to have:
.set(**kw)
.update(whereclause, **kw) # this does table.update().execute()
.count(whereclause) # table.count(whereclause).scalar()
.delete_one(id)
.load(*args) # returns a mapper with a bunch of eager loads
.add_properties(dict)
Luckily, great minds think alike and I was able to
The right usage of append_whereclause() seems to be:
s = sometable.select()
s.append_whereclause(col==val)
etc.
I just had a kind of tough time recently when I actually assigned the
result instead:
s = sometable.select()
s = s.append_whereclause(col==val)
Granted, this was a mistake I
On Jun 1, 2007, at 3:04 PM, Eric Ongerth wrote:
The right usage of append_whereclause() seems to be:
s = sometable.select()
s.append_whereclause(col==val)
etc.
I just had a kind of tough time recently when I actually assigned the
result instead:
s = sometable.select()
s =
On Friday 01 June 2007 21:38:15 Michael Bayer wrote:
On Jun 1, 2007, at 1:24 PM, Michael Bayer wrote:
and we can even bring back a modified version auto-descend in
that case:
query(A).filter_by(C, lala=5)
since above its not ambiguous.
actually, scratch that. C can be related to
On Jun 1, 2007, at 5:33 PM, [EMAIL PROTECTED] wrote:
heh, if i remember how whole-heartly u defended this autodescend thing
some months ago...
we didnt have generative behavior built into query so there was no
way to conveniently get at an attribute based on a join.
and more IMO, i
On 6/1/07, Michael Bayer [EMAIL PROTECTED] wrote:
What I'd rather see is either an error warning not to assign the
result to anything, or to just have foo.append_whereclause() return
the resulting foo. Is that a reasonable request, or are there reasons
it shouldn't be done? Unnecessary,
assign_mapper is doing five different things:
1 Hide the session context and session
2 .query()
3 shadowed query methods (get*/select*/count/join*/etc)
4 shadowed session methods (flush/delete/save/etc)
5 connecting a DynamicMetaData whenever it needs to
(1) we all
On Jun 1, 2007, at 5:58 PM, Mike Orr wrote:
Returning None is a Python standard, see list.sort(). Making select
generative is OK, but it should either modify the select in place or
return a new one, not modify it and return it. That's a Perlism.
There should be one-- and preferably only
On 6/1/07, Michael Bayer [EMAIL PROTECTED] wrote:
the modify in
place and return it thing is also how Hibernate criteria queries work.
I know nothing about Hibernate. Why is it so great and why are we
imitating it? According to Wikipedia it's a Java db framework. So we
should make sure
On Jun 1, 2007, at 6:47 PM, Mike Orr wrote:
(4) I haven't used so I'm not sure if it's better or worse than
session.* . But grafting fewer rather than more methods onto the
mapped class makes sense.
instance.flush() is often misused, since flush() with just one
instance wont always flush
plus *another* option to think about here, which was actually my
first (suppressed) instinct, but now i just saw that Hibernate sort
of does this, is to *keep* the joinpoint in and just have the
join function reset the joinpoint on each invocation.
so,
session.query(User).join(['orders',
No weak-reference error this morning, hooray. I'll be watching it for
a few days.
Could using a BoundMetaData in my model be contributing to the
problem? I have the following structure:
===
ctx = get_session_context()
# A custom function that creates a session_context like
#
On Jun 1, 2007, at 7:07 PM, Mike Orr wrote:
On 6/1/07, Michael Bayer [EMAIL PROTECTED] wrote:
the modify in
place and return it thing is also how Hibernate criteria queries
work.
I know nothing about Hibernate. Why is it so great and why are we
imitating it? According to Wikipedia
On Jun 1, 2007, at 7:22 PM, Mike Orr wrote:
No weak-reference error this morning, hooray. I'll be watching it for
a few days.
Could using a BoundMetaData in my model be contributing to the
problem? I have the following structure:
i cant see how. all of that code internally uses
On 6/1/07, Michael Bayer [EMAIL PROTECTED] wrote:
Mike Orr wrote:
Could we have session.engine be an alias for session.bind_to? Pretty
please? The only reason I leave a top-level 'engine' around is in
case I need it for something, because .bind_to is so non-obvious.
pylons is the
On 6/1/07, Michael Bayer [EMAIL PROTECTED] wrote:
pylons is the reason pulling the engine off the session is even
becoming popular, because it is actually using the bind_to feature,
as well as that it didnt really create any easy way to get at the
engine repository (not to mention the issues
I'm transforming a query from .select(offset=start, limit=rpp) to
.query()[:] syntax.
('rpp' means records per page.) Stupidly I transformed it directly into:
.query()[start:rpp]
which in one transaction evaluates to:
.query()[1420:20]
This causes a SQL syntax error with the actual
40 matches
Mail list logo
