Hey list, are you confused by the current system ? Please let me know.
the only change I would favor here would be to merge connect into
MetaData, BoundMetaData and DynamicMetaData stay around for backwards
compat for probably forever.
Not actually confused by the system. Since I need to
I think its more
confusing for the API to break backwards-compatibility every 5 or 6
releases.
Also i think adding a whole new class DelayedMetaData,
which is literally just to avoid passing a flag, well i wont say
insane but its a little obsessive.
Agreed here.
Hey list, are you
in my many to many relation, i've an abiguous primary key so Sa tell me:
sqlalchemy.exceptions.ArgumentError: Error determining primary and/or
secondary join for relationship 'xxx' between mappers 'Mapper|Yyy|yy'
and 'Mapper|Xxx|xxx'. If the underlying error cannot be corrected, you
should
Glauco ha scritto:
in my many to many relation, i've an abiguous primary key so Sa tell me:
sqlalchemy.exceptions.ArgumentError: Error determining primary and/or
secondary join for relationship 'xxx' between mappers 'Mapper|Yyy|yy'
and 'Mapper|Xxx|xxx'. If the underlying error cannot be
Hi,
I just came across Documentation and it's not clear to me how to use
connection pooling.
When invoked
db=create_engine()
the pool parameter is set to None by default, right?
In Connection pooling section of docs, it's said
For most cases, explicit access to the pool module is not required
can I have some feedback from the list who is using the thread-local
capability of DynamicMetaData, and/or are using global_connect() ?
(another feature i didnt like but it was me bowing to early pressure
from TG users).
Probably this will be no surprise, since I contributed most of the
On Mar 13, 11:59 am, Gaetan de Menten [EMAIL PROTECTED] wrote:
I only discovered (or at least understood) this thread localness
of DynamicMetaData, and honestly, I don't understand in what case
it can be useful. It seems like the thread localness is limited
to the engine connected to
On 3/14/07, JP [EMAIL PROTECTED] wrote:
On Mar 13, 11:59 am, Gaetan de Menten [EMAIL PROTECTED] wrote:
I only discovered (or at least understood) this thread localness of
DynamicMetaData, and honestly, I don't understand in what case it can
be useful. It seems like the thread localness is
Hi,
it's not obvious, nothing said in a docs about default pool setup and
The Database options section has:
pool=None - an actual pool instance.
that's why I conclude that pool is NOT setup by default. I just want
to confirm that.
Valentin.
On Mar 14, 1:34 pm, Sébastien LELONG [EMAIL PROTECTED]
On Mar 14, 2007, at 12:49 PM, Glauco wrote:
This is perfect but when i try to use count function the SQL
composer try to do an expensive sql.
In [63]: print select([tbl['azienda'].c.id], tbl['azienda']).count()
SELECT count(id) AS tbl_row_count
FROM (SELECT azienda.id AS id
FROM
Perhaps he's looking for an upsert function? That's sometimes handy, and to
be truly useful would have to be able to use any given key on the table.
I hacked up an upsert for SQLObject once, but it was so ugly I never
contributed it. It did make the poor man's replication system that I was
On 12 mrt, 21:47, polaar [EMAIL PROTECTED] wrote:
FYI, specifying module=pyodbc didn't seem to help wrt the
ConcurrentModificationError. Didn't have very much time, had a (very)
quick look at the code in mssql.py, and at first sight, it would seem
that sane_rowcount is a global variable that
if you read the entire document, it should be pretty clear that the
engine does not function without a connection pool, so there has to
be one present by default.
The Engine will create its first connection to the database when a
SQL statement is executed. As concurrent statements are
OK, guess not. Committed in rev 2411
On 3/4/07, Rick Morrison [EMAIL PROTECTED] wrote:
This is a one-liner fix that I already have in my tree. It might be good
practice one to get your feet wet if you want to take a swag at it, Bret...
Rick
On 3/4/07, Bret Aarden [EMAIL PROTECTED] wrote:
well at least make a full blown patch that doesnt break all the other
DB's. notice that an Engine doesnt just execute Compiled objects, it
can execute straight strings as well. thats why the dialect's
do_execute() and do_executemany() take strings - they are assumed to
go straight to a
It's the second case, that is, it sniffs out what modules are installed.
As I said before, this
(along with other modules that effectively do the same thing), is up
for a clean-up soon, see ticket #480.
Rick
On 3/14/07, polaar [EMAIL PROTECTED] wrote:
{'pyodbc': use_pyodbc, 'adodbapi':
because
a) SQL-standard says names are caseless - Fun anf fUn are same thing
b) most SQLs allow mixed case but require it in quotes, and some are
_very_ picky about it (postgres)
c) readability - lowercase names differs well from uppercase reserved
words
On Thursday 15 March 2007 06:26:03
17 matches
Mail list logo
