[sqlalchemy] echo-es
in 0.3, one could do meta = MetaData( whatever, echo=True) later, early 0.4, the echo kwarg was gone, so it got less convenient, adding another line: meta.bind.echo = True As of latest trunk, neither works, one has to explicitly do meta = MetaData( create_engine(whatever, echo=True)) which is probably fine for explicitness with lots of args, but is not very useful for a simple echo. IMO it is important to get the simplest use case (minimum explicit typing): meta = MetaData( dburl, echo=True) working. Another thing, the dots that are produced by unittests magically disappear if meta.bind.echo = True, very interesting.. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Self-referential property
Dear list,
I'm still working on a DNS administration web interface and have to deal
with DNS records. This is what I have so far:
---
import sqlalchemy as sql
import sqlalchemy.orm as orm
from sqlalchemy.databases.postgres import PGInet
records_table = sql.Table(
'records', metadata,
sql.Column('id', sql.Integer, primary_key=True),
sql.Column('name', sql.Unicode(80)),
sql.Column('type', sql.Unicode(10)),
sql.Column('content', sql.Unicode(200)),
sql.Column('inet', PGInet),
)
class Record(MyOrm):
@property
def ptr_records(self):
Returns matching PTR records for an A record
assert self.type=='A'
assert self.inet!=None
return Record.q().filter_by(type='PTR', inet=self.inet)
orm.mapper(Record, records_table)
---
So for an address (A) entry I'd like to find out if there is a matching
PTR record. Match criteria are the inet column. So if I have a certain
A record...
a = query(Record).filter_by(type='A').one()
...and like to find out the matching PTR records I would call...
ptr = a.ptr_records
This works okay so far. But somehow it feels wrong to do queries in
properties I add to the Record class. Especially since the ptr_records
do not get cached and the query is run every time I access this
property. So I wondered how to do that as properties of the mapper. I
started with
http://www.sqlalchemy.org/docs/04/mappers.html#advdatamapping_relation_customjoin
But that example deals with User and Address tables and not with
self-references. I suspect I have to alias the table. Roughly I'm
thinking of something like:
properties={
'ptr_records': relation(Record, primaryjoin=and_(
records_table.c.type=='PTR',
records_table.c.inet=records_table2.c.inet
))
}
I don't know how to say match other Record objects where the 'inet'
column contains the same value. How do I do that correctly?
Cheers
Christoph
P.S.: I simplified the models for this posting so bear with me if this
is not code that would run as is.
--~--~-~--~~~---~--~~
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 group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: echo-es
Another thing, the dots that are produced by unittests magically disappear if meta.bind.echo = True, very interesting.. shoot me, thats my problem --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: large amount of insert
Michael Bayer ha scritto: well at the very least you want to ensure that executemany() is being used for the inserts (i.e. with sqlalchemy, dont use ORM, use connection.execute(statement, [param, param, param...]). If you use SQLAlchemy's executemany() facilities, we've just increased their efficiency by about 60% in the 0.4.0beta3 release, we had some huge latency issues with this particular operation previously. faster still is to use raw DBAPI: conn = engine.connect() conn.connection.executemany(statement, [params...]) If this don't cause thread or other problem with SA, i think this is the best solution, i can split my n insert query in segments of 100 qry a time. using copy from..file is probably very fast, but its a little weird to use that in the context of a web request. I think too... Thank you -- ++ Glauco Uri - Programmatore glauco(at)allevatori.com Sfera Carta Software(r) [EMAIL PROTECTED] Via Bazzanese,69 Casalecchio di Reno(BO) - Tel. 051591054 ++ --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Self-referential property
On Aug 22, 2007, at 8:27 AM, Christoph Haas wrote:
But that example deals with User and Address tables and not with
self-references. I suspect I have to alias the table. Roughly I'm
thinking of something like:
properties={
'ptr_records': relation(Record, primaryjoin=and_(
records_table.c.type=='PTR',
records_table.c.inet=records_table2.c.inet
))
}
I don't know how to say match other Record objects where the 'inet'
column contains the same value. How do I do that correctly?
Well the issue here is that while its a self-referential relationship
you're dealing with, its not an adjacency list model, which is
really what our self-referential relation() is designed to do.
Normally you can use the remote_side attribute to indicate
whichever column on the join condition is remote, but here its the
same column.
Doing the alias thing is possibly a solution. it would look like this:
records2 = records.alias()
rmapper = mapper(Record, records2, non_primary=True)
'ptr_records':relation(rmapper, primaryjoin=and_(
records2.c.type=='PTR', records.c.inet=records2.c.inet),
viewonly=True)
)
the above should work in theory but I havent tried it. notice that
the records2 alias indicates the child side of the relationship so
its the one which gets the PTR criterion. viewonly=True is to
eliminate whatever issues arise in calculating the persistence aspect
of the relation since you only need loading here.
--~--~-~--~~~---~--~~
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 group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: echo-es
will restore engine.echo today. leaving it out on session and pool, however (bet you didnt know they had echo too...) On Aug 22, 2007, at 5:11 AM, svilen wrote: in 0.3, one could do meta = MetaData( whatever, echo=True) later, early 0.4, the echo kwarg was gone, so it got less convenient, adding another line: meta.bind.echo = True As of latest trunk, neither works, one has to explicitly do meta = MetaData( create_engine(whatever, echo=True)) which is probably fine for explicitness with lots of args, but is not very useful for a simple echo. IMO it is important to get the simplest use case (minimum explicit typing): meta = MetaData( dburl, echo=True) working. Another thing, the dots that are produced by unittests magically disappear if meta.bind.echo = True, very interesting.. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Self-referential property
On Wed, Aug 22, 2007 at 12:37:32PM -0400, Michael Bayer wrote:
On Aug 22, 2007, at 8:27 AM, Christoph Haas wrote:
But that example deals with User and Address tables and not with
self-references. I suspect I have to alias the table. Roughly I'm
thinking of something like:
properties={
'ptr_records': relation(Record, primaryjoin=and_(
records_table.c.type=='PTR',
records_table.c.inet=records_table2.c.inet
))
}
I don't know how to say match other Record objects where the 'inet'
column contains the same value. How do I do that correctly?
Well the issue here is that while its a self-referential relationship
you're dealing with, its not an adjacency list model, which is
really what our self-referential relation() is designed to do.
Understood. That's the easy/supported case that I will need at a later
time. :)
Normally you can use the remote_side attribute to indicate
whichever column on the join condition is remote, but here its the
same column.
Doing the alias thing is possibly a solution. it would look like this:
records2 = records.alias()
rmapper = mapper(Record, records2, non_primary=True)
'ptr_records':relation(rmapper, primaryjoin=and_(
records2.c.type=='PTR', records.c.inet=records2.c.inet),
viewonly=True)
)
the above should work in theory but I havent tried it.
notice that the records2 alias indicates the child side of the
relationship so its the one which gets the PTR criterion.
viewonly=True is to eliminate whatever issues arise in calculating
the persistence aspect of the relation since you only need loading
here.
Tried it. It raises this error:
ArgumentError: Can't locate any foreign key columns in primary join
condition 'records_1.type = :records_1_type AND records.inet =
records_1.inet' for relationship 'Record.ptr_records (Record)'.
Specify 'foreign_keys' argument to indicate which columns in the
join condition are foreign.
So I added:
foreign_keys=[records_table2.c.inet]
The error disappeared. But getting the joined PTR records for a certain
inet took very long. So I analyzed the query that SQLAlchemy did:
SELECT records.id AS records_id, records.domain_id AS
records_domain_id, records.dhcpzone_id AS records_dhcpzone_id,
records.name AS records_name, records.type AS records_type,
records.content AS records_content, records.ttl AS records_ttl,
records.prio AS records_prio, records.change_date AS
records_change_date, records.mac_address AS records_mac_address,
records.inet AS records_inet
FROM records, records AS records_1
WHERE records_1.type = %(records_1_type)s AND %(param_2)s =
records_1.inet ORDER BY records.id
{'records_1_type': 'PTR', 'param_2': '10.20.30.40'}
The FROM records, records AS records_1 looks suspiciously like a
cartesian product. And I get all possible results - not just rows with
type=='PTR'. The childs from records_1 have the right criteria. But
I get all records. :(
I'm not sure if JOIN is the right paradigm here. Usually I'd use a
SELECT. But select in SQLAlchemy's world doesn't seem to return mapped
objects but rather plain rows. I assume it's not supported to add a
filter() statement as a property?
Perhaps you have another hint. Would be a pity to give up and use my
dirty @property method. Thanks so far.
Christoph
--~--~-~--~~~---~--~~
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 group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: How can I do join on a self-referential m2m relation?
Hallo Mike,
first of all, thank you for your great great sqlalchemy!
On Aug 22, 6:49 pm, Michael Bayer [EMAIL PROTECTED] wrote:
im not sure about how elixir does bi-directional relationships but it
seems strange that you have set up the children and parents
relationships twice in both directions.but this might be elixir's
strangeness.
Yes, i must declare the relation twice in order to get a bi-dir one.
While the results you're getting below arent right, I would also
point out that the above query doesnt actually gain anything by
having the join to children since those rows arent being filtered
or fetched...unless you're just illustrating for the sake of example.
My bad!
What I actually want is a eager load on the self-referential m2m
relation.
To make things clearer, I rewrite the demo in pure SA this time:
from sqlalchemy import *
from sqlalchemy.orm import *
metadata = MetaData(create_engine('postgres://localhost/test'))
widget = Table('widget', metadata,
Column('id', Integer, primary_key=True),
Column('name', Unicode(40), nullable=False, unique=True),
)
widget_rel = Table('widget_parents__widget_children', metadata,
Column('parent_id', Integer, ForeignKey('widget.id')),
Column('child_id', Integer, ForeignKey('widget.id')),
UniqueConstraint('parent_id', 'child_id'),
)
class Widget(object):
pass
mapper(Widget, widget, properties={
'children': relation(Widget, secondary=widget_rel,
primaryjoin=widget_rel.c.parent_id==widget.c.id,
secondaryjoin=widget_rel.c.child_id==widget.c.id,
lazy=False, join_depth=1,
)
})
sess = scoped_session(sessionmaker())()
and I want eager load the widget whose id=1 and all it's children if
any:
sess.query(Widget).filter(Widget.id==1).all()
returns:
DBAPIError: (ProgrammingError) missing FROM-clause entry for table
widget_1
LINE 2: ... ON widget_parents__widget_children_2.parent_id =
widget_1.i...
^
'SELECT widget_1.id AS widget_1_id, widget_1.name AS widget_1_name,
widget.id AS widget_id, widget.name AS widget_name \nFROM widget LEFT
OUTER JOIN widget_parents__widget_children AS
widget_parents__widget_children_2 ON
widget_parents__widget_children_2.parent_id = widget_1.id LEFT OUTER
JOIN widget AS widget_1 ON widget_parents__widget_children_2.child_id
= widget_1.id \nWHERE widget.id = %(widget_id)s ORDER BY
widget.id' {'widget_id': 1}
The problem is PropertyAliasedClauses returns the same alias name for
both primary and secondary join, which is in this case wrong.
I find no where in the docs says about eager load on self-referential
m2m.
Is that possible?
Best!
Jian
--~--~-~--~~~---~--~~
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 group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: echo-es
will restore engine.echo today. what about Metadata's? why not leave some enginetype-indepedent kwargs there (or at least echo, its the most used in lets-try-this-now cases), which go together with the bind to the create()? i know i know explicit is better than implicit... noone would be forced to use them ;-) something like def __init__( ..., echo =None): ... me.echo = echo def create( ..., echo=None, **kargs4engine) if echo is None: echo me.echo .. create engine( bind, echo=echo, **kargs4engine) ? leaving it out on session and pool, however (bet you didnt know they had echo too...) i know but i always assumed all that is working (and it always has been so far) and its me/request going wrong, hence the sql echo... On Aug 22, 2007, at 5:11 AM, svilen wrote: in 0.3, one could do meta = MetaData( whatever, echo=True) later, early 0.4, the echo kwarg was gone, so it got less convenient, adding another line: meta.bind.echo = True As of latest trunk, neither works, one has to explicitly do meta = MetaData( create_engine(whatever, echo=True)) which is probably fine for explicitness with lots of args, but is not very useful for a simple echo. IMO it is important to get the simplest use case (minimum explicit typing): meta = MetaData( dburl, echo=True) working. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: SA 0.4, pylons 0.9.6rc3
Hi Anil,
The recent 0.4 betas have an all-new MySQL table reflection routine
that's being tried out. It's possible that it's not picking up
your primary key when it should- could you send in the output of
SHOW CREATE TABLE for this table, either on or off list? Also
there should be a warning issued if a key is detected but is not
registered on the table.
Anil wrote:
Module entic.controllers.access:74 in _login
# select our user
user_q = model.Session.query(model.User)
user = user_q.filter_by(mail=mail)
user_q = model.Session.query(model.User)
Module sqlalchemy.orm.scoping:68 in do
Module sqlalchemy.orm.session:642 in query
Module sqlalchemy.orm.mapper:1648 in class_mapper
Module sqlalchemy.orm.mapper:236 in compile
Module sqlalchemy.orm.mapper:251 in _compile_all
Module sqlalchemy.orm.mapper:278 in _do_compile
Module sqlalchemy.orm.mapper:446 in _compile_tables
class 'sqlalchemy.exceptions.ArgumentError': Could not assemble
any primary key columns for mapped table 'User'
I have defined a table as such:
user_table = Table(User, metadata,
autoload=True, autoload_with=config['pylons.g'].sa_engine)
mapper(User, user_table, properties = {
'alerts':
relation(Alert, cascade=all, delete-orphan, lazy=False),
'hosts': relation(Host,
cascade=all, delete-orphan, lazy=False)
})
I do have a pri key set in the User table (MySQL).
I tried to explicitly specify a primary_key even with the
autoload=True, but I get other exceptions after this.
Is this a bug or an incorrect usage?
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 group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: SA 0.4, pylons 0.9.6rc3
| User | CREATE TABLE `User` (
`id` int(10) unsigned NOT NULL auto_increment,
`location_id` int(10) unsigned NOT NULL,
`mail` varchar(45) NOT NULL,
`password` varchar(45) NOT NULL,
`salt` varchar(8) NOT NULL,
`phone` varchar(24) default NULL,
`organization` varchar(45) default NULL,
`status` tinyint(1) NOT NULL default '1',
`ping_max` tinyint(3) unsigned NOT NULL default '1',
`probe_max` tinyint(3) unsigned NOT NULL default '1',
PRIMARY KEY USING BTREE (`id`),
KEY `FK_User_1` (`location_id`),
CONSTRAINT `FK_User_1` FOREIGN KEY (`location_id`) REFERENCES
`Location` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
Actually, there was some information in the logs that I just noticed
that might help detect the problem (some kind of unicode issue?):
12:58:21,710 INFO [sqlalchemy.engine.base.Engine.0x..50] SHOW CREATE
TABLE `User`
12:58:21,711 INFO [sqlalchemy.engine.base.Engine.0x..50] None
12:58:21,802 WARNING sqlalchemy
/home/aj99243/lib/python2.5/site-packages/SQLAlchemy-0.4.0beta3-py2.5.egg/sqlalchemy/databases/mysql.py:1891:
RuntimeWarning: Unknown schema content: u' PRIMARY KEY USING BTREE
(`id`),'
repr(line)))
12:58:21,805 INFO sqlalchemy.engine.base.Engine.0x..50 SHOW VARIABLES
LIKE 'character_set%%'
On 8/22/07, jason kirtland [EMAIL PROTECTED] wrote:
Hi Anil,
The recent 0.4 betas have an all-new MySQL table reflection routine
that's being tried out. It's possible that it's not picking up
your primary key when it should- could you send in the output of
SHOW CREATE TABLE for this table, either on or off list? Also
there should be a warning issued if a key is detected but is not
registered on the table.
Anil wrote:
Module entic.controllers.access:74 in _login
# select our user
user_q = model.Session.query(model.User)
user = user_q.filter_by(mail=mail)
user_q = model.Session.query(model.User)
Module sqlalchemy.orm.scoping:68 in do
Module sqlalchemy.orm.session:642 in query
Module sqlalchemy.orm.mapper:1648 in class_mapper
Module sqlalchemy.orm.mapper:236 in compile
Module sqlalchemy.orm.mapper:251 in _compile_all
Module sqlalchemy.orm.mapper:278 in _do_compile
Module sqlalchemy.orm.mapper:446 in _compile_tables
class 'sqlalchemy.exceptions.ArgumentError': Could not assemble
any primary key columns for mapped table 'User'
I have defined a table as such:
user_table = Table(User, metadata,
autoload=True, autoload_with=config['pylons.g'].sa_engine)
mapper(User, user_table, properties = {
'alerts':
relation(Alert, cascade=all, delete-orphan, lazy=False),
'hosts': relation(Host,
cascade=all, delete-orphan, lazy=False)
})
I do have a pri key set in the User table (MySQL).
I tried to explicitly specify a primary_key even with the
autoload=True, but I get other exceptions after this.
Is this a bug or an incorrect usage?
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 group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Self-referential property
On Aug 22, 2007, at 2:31 PM, Christoph Haas wrote:
The error disappeared. But getting the joined PTR records for a
certain
inet took very long. So I analyzed the query that SQLAlchemy did:
SELECT records.id AS records_id, records.domain_id AS
records_domain_id, records.dhcpzone_id AS records_dhcpzone_id,
records.name AS records_name, records.type AS records_type,
records.content AS records_content, records.ttl AS records_ttl,
records.prio AS records_prio, records.change_date AS
records_change_date, records.mac_address AS records_mac_address,
records.inet AS records_inet
FROM records, records AS records_1
WHERE records_1.type = %(records_1_type)s AND %(param_2)s =
records_1.inet ORDER BY records.id
{'records_1_type': 'PTR', 'param_2': '10.20.30.40'}
The FROM records, records AS records_1 looks suspiciously like a
cartesian product. And I get all possible results - not just rows with
type=='PTR'. The childs from records_1 have the right criteria. But
I get all records. :(
OK, it seems like its using the primary mapper for the lazy load and
not the secondary mapper you created. I think at this point I'd
have to dig in and see whats up, except im going out of town
tomorrow. So you should add a trac ticket with an example script
that one of us can look at.
I'm not sure if JOIN is the right paradigm here. Usually I'd use a
SELECT. But select in SQLAlchemy's world doesn't seem to return
mapped
objects but rather plain rows. I assume it's not supported to add a
filter() statement as a property?
its supported. you can use a dynamic_loader() relation, which
basically attaches a Query as the collection used by the relation().
However, the self-referential-non-adjacency list thing happening here
might get in the way again.
Perhaps you have another hint. Would be a pity to give up and use my
dirty @property method. Thanks so far.
the @property youre using *is* the most straightforward way to do
this. if caching is the only issue, just have your @property store
the result in a list and return that. there isnt really a relation
happening here, no foreign key or anything, so to some degree you're
repurposing what relation() is meant to do (but is still very
common..everyone wants relation() to wash their dishes and take out
their trash :) )
--~--~-~--~~~---~--~~
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 group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: How can I do join on a self-referential m2m relation?
Hi Jian -
yes, its the PropertyAliasedClauses. I put in a fix + a test based
on your example in r3410. i didnt yet add a test for more levels
deep yet, though, so see how that goes.
- mike
On Aug 22, 2007, at 3:07 PM, Jian Luo wrote:
class Widget(object):
pass
mapper(Widget, widget, properties={
'children': relation(Widget, secondary=widget_rel,
primaryjoin=widget_rel.c.parent_id==widget.c.id,
secondaryjoin=widget_rel.c.child_id==widget.c.id,
lazy=False, join_depth=1,
)
})
sess = scoped_session(sessionmaker())()
and I want eager load the widget whose id=1 and all it's children if
any:
sess.query(Widget).filter(Widget.id==1).all()
--~--~-~--~~~---~--~~
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 group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] SQLAlchemy 0.4 beta4 released
I've just put beta4 out, which fixes some important issues and also has lots more performance enhancements. In particular, the connection pool works a little differently now, so please let us know if any stability issues arise. One caveat with this release is that I just noticed that the SQL statement logging is double logging if you configure it via regular Python logging. Sorry ! I just fixed it in SVN revision 3410 if that's an issue. otherwise heres the changelog: 0.4.0beta4 -- - Tidied up what ends up in your namespace when you 'from sqlalchemy import *': - 'table' and 'column' are no longer imported. They remain available by direct reference (as in 'sql.table' and 'sql.column') or a glob import from the sql package. It was too easy to accidentally use a sql.expressions.table instead of schema.Table when just starting out with SQLAlchemy, likewise column. - internal-ish classes like ClauseElement, FromClause, NullTypeEngine, etc., are also no longer imported into your namespace - the 'Smallinteger' compatiblity name (small i!) is no longer imported, but remains in schema.py for now. SmallInteger (big I!) is still imported. - the connection pool uses a threadlocal strategy internally to return the same connection already bound to a thread, for contextual connections; these are the connections used when you do a connectionless execution like insert().execute(). This is like a partial version of the threadlocal engine strategy but without the thread-local transaction part of it. We're hoping it reduces connection pool overhead as well as database usage. However, if it proves to impact stability in a negative way, we'll roll it right back. - Fix to bind param processing such that False values (like blank strings) still get processed/encoded. - Fix to select() generative behavior, such that calling column(), select_from(), correlate(), and with_prefix() does not modify the original select object [ticket:752] - Added a legacy adapter to types, such that user-defined TypeEngine and TypeDecorator classes which define convert_bind_param() and/or convert_result_value() will continue to function. Also supports calling the super() version of those methods. - Added session.prune(), trims away instances cached in a session that are no longer referenced elsewhere. (A utility for strong-ref identity maps). - Added close() method to Transaction. Closes out a transaction using rollback if it's the outermost transaction, otherwise just ends without affecting the outer transaction. - Transactional and non-transactional Session integrates better with bound connection; a close() will ensure that connection transactional state is the same as that which existed on it before being bound to the Session. - Modified SQL operator functions to be module-level operators, allowing SQL expressions to be pickleable. [ticket:735] - Small adjustment to mapper class.__init__ to allow for Py2.6 object.__init__() behavior. - Fixed 'prefix' argument for select() - Connection.begin() no longer accepts nested=True, this logic is now all in begin_nested(). - fixes to new dynamic relation loader involving cascades --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] minimizing number of connections created
Hi,
the following code creates 2 connections.
Is there way to make it 1, either by making the Table share
connection1 or
by releasing the connection Table used after it loaded the metadada?
TIA
connect_s = 'mysql://%s:[EMAIL PROTECTED]/%s' % (user, pw, server, db)
engine = sqlalchemy.create_engine(connect_s)
connection1 = engine.connect() #connection proxy
# engine.echo=True # for debug
md = sqlalchemy.BoundMetaData(engine)
table = sqlalchemy.Table('name', md, autoload = True)
--~--~-~--~~~---~--~~
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 group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: SA 0.4, pylons 0.9.6rc3
Anil wrote: Actually, there was some information in the logs that I just noticed that might help detect the problem (some kind of unicode issue?): 12:58:21,710 INFO [sqlalchemy.engine.base.Engine.0x..50] SHOW CREATE TABLE `User` 12:58:21,711 INFO [sqlalchemy.engine.base.Engine.0x..50] None 12:58:21,802 WARNING sqlalchemy /home/aj99243/lib/python2.5/site-packages/SQLAlchemy-0.4.0beta3-py2.5.egg/sqlalchemy/databases/mysql.py:1891: RuntimeWarning: Unknown schema content: u' PRIMARY KEY USING BTREE (`id`),' repr(line))) 12:58:21,805 INFO sqlalchemy.engine.base.Engine.0x..50 SHOW VARIABLES LIKE 'character_set%%' Ok, this is now fixed in r3412. Sorry it didn't make it into beta4! It's a *very* simple change if you want to update your copy of SQLAlchemy directly: http://www.sqlalchemy.org/trac/changeset/3412 --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: minimizing number of connections created
use autoload_with=someconnection when you create the Table. Dont
use BoundMetaData.
On Aug 22, 2007, at 5:53 PM, mc wrote:
Hi,
the following code creates 2 connections.
Is there way to make it 1, either by making the Table share
connection1 or
by releasing the connection Table used after it loaded the metadada?
TIA
connect_s = 'mysql://%s:[EMAIL PROTECTED]/%s' % (user, pw, server, db)
engine = sqlalchemy.create_engine(connect_s)
connection1 = engine.connect() #connection proxy
# engine.echo=True # for debug
md = sqlalchemy.BoundMetaData(engine)
table = sqlalchemy.Table('name', md, autoload = True)
--~--~-~--~~~---~--~~
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 group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
