Re: [sqlalchemy] polymorphic single table inheritance with __mapper_args__ automagically set
this is a bug and will be fixed by 0.6.5, because originally @classproperty was
only supposed to be recognized in mixins, but as of 0.6.4 we started allowing
it to be recognized in a base class (but missed __mapper_args__, __tablename__,
__table_args__).For now declare a mixin:
class CarMixin(object):
@classproperty
def __mapper_args__(cls):
if cls.__name__ == Car:
return {polymorphic_on:cls.class_name,
polymorphic_identity:Car, with_polymorphic:*}
else:
return {polymorphic_identity:cls.__name__}
class Car(CarMixin, Base):
On Sep 19, 2010, at 5:56 PM, Eduardo Robles Elvira wrote:
Hello everyone:
I'm having some trouble with polymorphic single table inheritance. I
want my subclasses (Ferrari is a subclass of Car) to have the
__mapper_args__ automatically set. How could I do that. I've got this:
class Car(Base):
__tablename__ = 'car'
id = Column(Integer, primary_key=True)
class_name = Column(Unicode(128), nullable=False)
__mapper_args__ = {polymorphic_on:class_name,
polymorphic_identity:Car, with_polymorphic:*}
#...@classproperty
#def __mapper_args__(cls):
#if cls.__name__ == Car:
#return {polymorphic_on:cls.class_name,
polymorphic_identity:Car, with_polymorphic:*}
#else:
#return {polymorphic_identity:cls.__name__}
parent_id = Column(Integer, ForeignKey('car.id'))
children = relation(Car, backref=backref('parent', remote_side=id))
def __init__(self):
pass
def max_speed(self):
return 1000 km/h
class Ferrari(Car):
__mapper_args__ = {polymorphic_identity:Ferrari}
def __init__(self):
Car.__init__(self)
def max_speed(self):
return 320 km/h
I know that it doesn't make much sense for a car to have parent and
children cars, but that's what I need. So once the tables are created
in the db, I do something like:
parent_car = Car()
child_car = Ferrari()
child_car.parent = parent_car
orm.add(parent_car)
orm.add(child_car)
orm.commit()
print parent_car.children[0].max_speed()
print orm.query(Car).filter(Car.id ==
parent_car.children[0].id).one().max_speed()
And it works fine (prints 320 km/h twice)... but if I comment out
the __mapper_args__ lines in Car and Ferrari and uncomment the
@classproperty, it doesn't work fine because class_type doesn't get
properly set (i.e. its value is None) and I get a class_type cannot
be NULL exception. How could I fix it?
Thanks in advance,
Eduardo.
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] sqla 0.6.4, orm, problem with self-referring joins
On Sep 19, 2010, at 11:59 PM, me wrote: when i apply multiple joins to orm query, one of them self-referring, using (target, property) form sqla generates the wrong join criteria by selecting aliased table for the left side of the join. sess = Session() AliasedA = orm.aliased(A) q = sess.query(A) q = q.join((AliasedA, A.some_a)).options(orm.contains_eager(A.some_a, alias=AliasedA)) q = q.join((B, A.some_b)).options(orm.contains_eager(A.some_b)) print q -- SELECT b.id AS b_id, b.a_id AS b_a_id, b.b_data AS b_b_data, a_1.id AS a_1_id, a_1.a_data AS a_1_a_data, a.id AS a_id, a.a_data AS a_a_data FROM a JOIN assoc AS assoc_1 ON a.id = assoc_1.left_id JOIN a AS a_1 ON assoc_1.right_id = a_1.id JOIN b ON b.a_id = a_1.id here i expected JOIN b ON b.a_id = a.id not JOIN b ON b.a_id = a_1.id. This one is fun. join() always joins from the most recent FROM that it can. So here you want to first call reset_joinpoint() before calling join() again. The other traditional way is to use the separate orm.join() construct in conjunction with select_from(), though we are continuing to refine join() so that wont be needed (I eventually would like it to allow (left, right, onclause)...but we need to get everyone on a modernized calling form first). perhaps weight relations so that those that introduce alias are applied in right order? interestingbut this is really a 50/50 guess. Its just as likely someone really meant to join from AliasedA to B. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Sql Alchemy non Transactionnal
On Sep 20, 2010, at 10:37 AM, Christian Démolis wrote: Hi, Can i use SqlAlchemy in a non transactionnal way ? How can i do it? Session() has an autocommit=True flag that will commit every flush() operation immediately and not retain an open transaction during usage. You may very well want to set autoflush=False and call flush() manually with this mode. Note that there are still 'transactions' in use here, as the flush() will always place its multiple operations into a transaction. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Use regexp in like
On 9/20/2010 9:38 AM, Michael Hipp wrote:
Scratch that ... found this message:
http://www.mail-archive.com/sqlalchemy@googlegroups.com/msg18598.html
which says I should be able to do a 'SIMILAR TO' construct which is perhaps
somewhat more lightweight than a full regexp.
Can someone show me what I'm doing wrong here.
letter = 'A[0-9]+'
q = self.session.query(Car).filter_by(hist=False) \
.filter(Car.lane.op('SIMILAR TO') (letter)) \
.order_by(Car.lane)
I'm trying to match something that looks like 'A100'. But it produces a syntax
error:
OperationalError: (OperationalError) near SIMILAR: syntax error
...snip...
WHERE cars.hist = ? AND (cars.lane SIMILAR TO ?) ORDER BY cars.lane' (False,
'A[0-9]+')
Thanks,
Michael
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] sending sqlachemy mapped instances with yaml
Hi, I have two processes - server connected to database and client for displaying data. I would like to send objects readed from database on server side with yaml to client and then read display object data on client side. client process has no sqlachemy mappers. Without mappers I've got on client side: UnmappedInstanceError: Cannot deserialize object of type class 'model.Object' - no mapper() has been configured for this class within the current Python process! Is there any way to do it? Thanks, Łukasz signature.asc Description: OpenPGP digital signature
Re: [sqlalchemy] Use regexp in like
On 9/20/2010 10:09 AM, Michael Hipp wrote:
On 9/20/2010 9:38 AM, Michael Hipp wrote:
Scratch that ... found this message:
http://www.mail-archive.com/sqlalchemy@googlegroups.com/msg18598.html
which says I should be able to do a 'SIMILAR TO' construct which is perhaps
somewhat more lightweight than a full regexp.
Can someone show me what I'm doing wrong here.
letter = 'A[0-9]+'
q = self.session.query(Car).filter_by(hist=False) \
.filter(Car.lane.op('SIMILAR TO') (letter)) \
.order_by(Car.lane)
I'm trying to match something that looks like 'A100'. But it produces a syntax
error:
OperationalError: (OperationalError) near SIMILAR: syntax error
...snip...
WHERE cars.hist = ? AND (cars.lane SIMILAR TO ?) ORDER BY cars.lane' (False,
'A[0-9]+')
Strange. I couldn't see what was actually wrong with that SQL, so I ran it
directly against pg and it works fine. Is it possibly a quoting problem?
Michael
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Re: SQLAlchemy and Whoosh
On Sep 20, 2010, at 11:40 AM, Domen Kožar wrote: Thanks. Just to be sure, there is no need to handle rollback case when before_flush is called? If before_flush() fails, the transaction isn't affected by the exception thrown. The subtransaction doesn't begin until later in the flush() method. So after the exception thrown, the session is in whatever state your before_flush() left it. If that's state you want to throw away, its typical (at least recommended) that Sessions are always used in an outermost enclosing block that will rollback() after an exception is thrown.But the before_flush() exception is not different from if end-user code threw an exception before flush() was called. On Sep 20, 5:35 pm, Michael Bayer mike...@zzzcomputing.com wrote: On Sep 20, 2010, at 11:29 AM, Domen Kožar wrote: I'm writing simple glue layer between Whoosh and SQLAlchemy, the idea is that session event system reflects update of search index in whoosh (using celery). Looking at versioning example, it relies on before_flush event and make a snapshot. I need something similar, probably more complex. Here are the questions: - how to handle exceptions and rollbacks for changes done in before_flush just throw the exceptions outward, its another flush failure case. - does before_flush also handle bulk updates/deletes use after_bulk_update() / after_bulk_delete() - how to distinct new objects from existing in db (from session state) obj in session.new - maybe before_flush is not the best event? its usually the best place to do things. 0.7 will move to this interface (The extension interfaces will remain around for quite some time, at least throughout 0.8): from sqlalchemy import event # Session can be the Session class (global), a scoped_session, # a sessionmaker(), a session event.listen(my_before_flush, on_before_flush, Session) # filter for certain classes in the flush event.listen(my_before_flush, on_before_flush, MyClass) -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Use regexp in like
On Sep 20, 2010, at 11:54 AM, Michael Hipp wrote:
On 9/20/2010 10:09 AM, Michael Hipp wrote:
On 9/20/2010 9:38 AM, Michael Hipp wrote:
Scratch that ... found this message:
http://www.mail-archive.com/sqlalchemy@googlegroups.com/msg18598.html
which says I should be able to do a 'SIMILAR TO' construct which is perhaps
somewhat more lightweight than a full regexp.
Can someone show me what I'm doing wrong here.
letter = 'A[0-9]+'
q = self.session.query(Car).filter_by(hist=False) \
.filter(Car.lane.op('SIMILAR TO') (letter)) \
.order_by(Car.lane)
I'm trying to match something that looks like 'A100'. But it produces a
syntax
error:
OperationalError: (OperationalError) near SIMILAR: syntax error
...snip...
WHERE cars.hist = ? AND (cars.lane SIMILAR TO ?) ORDER BY cars.lane' (False,
'A[0-9]+')
Strange. I couldn't see what was actually wrong with that SQL, so I ran it
directly against pg and it works fine. Is it possibly a quoting problem?
is this pg8000 ? the ? as binds are suspect. that would be my guess.
Michael
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Use regexp in like
On 9/20/2010 10:57 AM, Michael Bayer wrote:
On Sep 20, 2010, at 11:54 AM, Michael Hipp wrote:
On 9/20/2010 10:09 AM, Michael Hipp wrote:
On 9/20/2010 9:38 AM, Michael Hipp wrote:
Scratch that ... found this message:
http://www.mail-archive.com/sqlalchemy@googlegroups.com/msg18598.html
which says I should be able to do a 'SIMILAR TO' construct which is perhaps
somewhat more lightweight than a full regexp.
Can someone show me what I'm doing wrong here.
letter = 'A[0-9]+'
q = self.session.query(Car).filter_by(hist=False) \
.filter(Car.lane.op('SIMILAR TO') (letter)) \
.order_by(Car.lane)
I'm trying to match something that looks like 'A100'. But it produces a syntax
error:
OperationalError: (OperationalError) near SIMILAR: syntax error
...snip...
WHERE cars.hist = ? AND (cars.lane SIMILAR TO ?) ORDER BY cars.lane' (False,
'A[0-9]+')
Strange. I couldn't see what was actually wrong with that SQL, so I ran it
directly against pg and it works fine. Is it possibly a quoting problem?
is this pg8000 ? the ? as binds are suspect. that would be my guess.
I've never used pg8000; this is psycopg2:
import psycopg2
psycopg2.__version__
'2.2.1 (dt dec ext pq3)'
Any help?
Thanks,
Michael
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Microsoft Access
Microsoft Access is supported, albeit experimentally in 0.5.8. Will this functionality make it past that at any point or has that been basically scrapped? -- Jeffrey D Peterson Webmaster Crary Industries, Inc. 237 12th St NW West Fargo, ND 58078 P: 701-499-5928 E: jeff.peter...@crary.com -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Microsoft Access
its not scrapped nor is any progress being made. A volunteer would have to step in to maintain and upgrade the module for current code. On Sep 20, 2010, at 1:46 PM, Jeff Peterson wrote: Microsoft Access is supported, albeit “experimentally” in 0.5.8. Will this functionality make it past that at any point or has that been basically scrapped? -- Jeffrey D Peterson Webmaster Crary Industries, Inc. 237 12th St NW West Fargo, ND 58078 P: 701-499-5928 E: jeff.peter...@crary.com -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Re: Serializable txns not useful on sqlite because do_begin() does nothing
On Sep 20, 4:22 pm, Michael Bayer mike...@zzzcomputing.com wrote: On Sep 20, 2010, at 3:51 PM, Randall Nortman wrote: On Sep 19, 1:52 pm, Michael Bayer mike...@zzzcomputing.com wrote: On Sep 19, 2010, at 9:54 AM, Randall Nortman wrote: The DB-SIG list agrees with you: http://mail.python.org/pipermail/db-sig/2010-September/005645.html And I have filed a bug on pysqlite: http://code.google.com/p/pysqlite/issues/detail?id=21 I fully expect the pysqlite folks to say but if we fix this it will break existing apps which assume they can SELECT all day without creating transactions, particularly since pysqlite is part of the python standard library. The current behavior (no transactions begun for SELECT) is documented, so many apps may depend on it. But I agree with you now that it's not SQLA's problem. They're going to say that SQLite locks the whole database file aggressively, which is why they dont start the trans until DML. That is fine, but there should be some option to control it. Where is the current behavior documented ? I couldn't find a link for that. http://docs.python.org/library/sqlite3.html#controlling-transactions By default, the sqlite3 module opens transactions implicitly before a Data Modification Language (DML) statement (i.e. INSERT/UPDATE/DELETE/ REPLACE), and commits transactions implicitly before a non-DML, non- query statement (i. e. anything other than SELECT or the aforementioned). This doesn't explicitly say doesn't open transactions before a SELECT statement, but that's clearly implied. Marc Lemburg seemed to be non-specific in his comments about when the transaction begins for isolation purposes - he just reiterated that its not transaction-per-statement. He said: Transactions start implicitly after you connect and after you call .commit() or .rollback(). In a follow-up on the thread, he was questioned about that and responded that logically, the transaction opens immediately after you connect, though waiting until the first statement is executed is an optimization. He's right, strictly speaking, because the logical model of serializable transaction isolation doesn't care whether the transaction is opened at the beginning of the connection or before the first query, because the first query determines when you first were exposed to the state of the database. The time between opening the connection and the first query is irrelevant because the client is not exposed to the database state during that period. To anybody not writing proofs of algorithmic correctness, though, the transaction should start immediately before the first statement executes, whether that statement modifies the database or merely queries it. I really prefer it say something so I know when the connection is starting to be worked with, and I'd prefer its not just well turn on connection pool logging. I've always thought BEGIN was clearest but I'm not going to fight hard on that, so just suggest something it could say. BEGIN (implicit) would be enough to clue me in that something may not be as it seems, and shouldn't confuse too many people (for more than a few moments). Or, leave it up to each dialect to echo something appropriate. DefaultDialect.do_begin() could echo BEGIN (implicit), and then any dialect which overrides do_begin() should echo something appropriate. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] get to dialect specific column type
I am trying to automatically generate the stored procedure I need for the localize stuff. So, would like to do something like this: aninst.__table__.c['created_at'].type.get_dbapi_type(dbapi) - to get e.g. TIMESTAMP for a DateTime column with Firebird SQL. What is the most efficient/easy way to get at dbapi from e.g. an instance? Isn't there some more elegant way then doing connection.engine.dialect.dbapi? Werner -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Re: sqla 0.6.4, orm, problem with self-referring joins
thanks for the help. it probably makes sense to alias the on-clause to
the query then, i just wasn't thinking in that way for some reason.
So here you want to first call reset_joinpoint() before calling join() again.
tried this and got the same result (doesn't join/outerjoin reset the
join point by default anyway):
sess = Session()
AliasedA = orm.aliased(A)
q = sess.query(A)
q = q.join((AliasedA,
A.some_a)).options(orm.contains_eager(A.some_a,alias=AliasedA))
q = q.reset_joinpoint() # added
q = q.join((B, A.some_b)).options(orm.contains_eager(A.some_b))
print q
use the separate orm.join() construct in conjunction with select_from()
started converting over to this but on a whim instead aliased all
joined targets *and* used that alias when specifying relations (as
well as in the relation chain passed to contains_eager).
it looks like that provides query.join/outerjoin enough information to
choose the desired lhs in the join clause.
updated example:
=
from sqlalchemy import create_engine, Table, MetaData, orm, Column,
Integer, ForeignKey, String
from sqlalchemy.interfaces import PoolListener
class Listener(PoolListener):
def connect(self, dbapi_con, con_record):
dbapi_con.execute(PRAGMA foreign_keys=ON)
engine = create_engine(
sqlite:///:memory:,
listeners=[Listener()],
echo=True)
Session = orm.sessionmaker(bind=engine)
metadata = MetaData()
c_table = Table(
c, metadata,
Column(id, Integer, primary_key=True),
Column(c_data, String)
)
a_table = Table(
a, metadata,
Column(id, Integer, primary_key=True),
Column(a_data, String),
Column(c_id, ForeignKey(c_table.c.id))
)
assoc_table = Table(
assoc, metadata,
Column(left_id, ForeignKey(a_table.c.id)),
Column(right_id, ForeignKey(a_table.c.id))
)
b_table = Table(
b, metadata,
Column(id, Integer, primary_key=True),
Column(a_id, ForeignKey(a_table.c.id)),
Column(b_data, String)
)
class C(object):
@staticmethod
def apply_relations(q, spec, parent, chain):
for name, sub_spec in spec.iteritems():
raise ValueError(Invalid relation '%s' % name)
return q
orm.mapper(C, c_table)
class B(object):
@staticmethod
def apply_relations(q, spec, parent, chain):
for name, sub_spec in spec.iteritems():
raise ValueError(Invalid relation '%s' % name)
return q
orm.mapper(B, b_table)
class A(object):
@staticmethod
def apply_relations(q, spec, parent, chain):
for name, sub_spec in spec.iteritems():
if name == some_a:
AliasA = orm.aliased(A)
chain.append(parent.some_a)
q = q.outerjoin((AliasA,
parent.some_a)).options(orm.contains_eager(*chain, alias=AliasA))
q = A.apply_relations(q, sub_spec, AliasA, chain)
del chain[-1]
elif name == some_b:
AliasB = orm.aliased(B)
chain.append(parent.some_b)
q = q.outerjoin((AliasB,
parent.some_b)).options(orm.contains_eager(*chain, alias=AliasB))
q = B.apply_relations(q, sub_spec, AliasB, chain)
del chain[-1]
elif name == c:
AliasC = orm.aliased(C)
chain.append(parent.c)
q = q.outerjoin((AliasC,
parent.c)).options(orm.contains_eager(*chain, alias=AliasC))
q = C.apply_relations(q, sub_spec, AliasC, chain)
del chain[-1]
else:
raise ValueError(Invalid relation '%s' % name)
return q
orm.mapper(
A, a_table,
properties={
some_a: orm.relation(
A,
primaryjoin=a_table.c.id ==
assoc_table.c.left_id,
secondary=assoc_table,
secondaryjoin=assoc_table.c.right_id ==
a_table.c.id),
some_b: orm.relation(
B,
primaryjoin=b_table.c.a_id == a_table.c.id),
c: orm.relation(C)
}
)
relation_spec = {
some_a: {
c: {
},
some_b: {
},
some_a: {
some_a: {
c: {
}
},
some_b: {
},
},
},
some_b: {
},
c: {
}
}
sess = Session()
q = sess.query(A)
q = A.apply_relations(q, relation_spec, A, [])
#q = sess.query(A)
#AliasedA1 = orm.aliased(A)
#q = q.join((AliasedA1,
A.some_a)).options(orm.contains_eager(A.some_a, alias=AliasedA1))
#AliasedA1C1 = orm.aliased(C)
#q = q.join((AliasedA1C1,
AliasedA1.c)).options(orm.contains_eager(A.some_a, AliasedA1.c,
alias=AliasedA1C1))
#AliasedA1B1 = orm.aliased(B)
#q = q.join((AliasedA1B1,
AliasedA1.some_b)).options(orm.contains_eager(A.some_a,
AliasedA1.some_b, alias=AliasedA1B1))
#AliasedA1A1 = orm.aliased(A)
#q = q.join((AliasedA1A1,
AliasedA1.some_a)).options(orm.contains_eager(A.some_a,
AliasedA1.some_a,
Re: [sqlalchemy] Re: sqla 0.6.4, orm, problem with self-referring joins
On Sep 20, 2010, at 6:44 PM, me wrote: thanks for the help. it probably makes sense to alias the on-clause to the query then, i just wasn't thinking in that way for some reason. So here you want to first call reset_joinpoint() before calling join() again. tried this and got the same result (doesn't join/outerjoin reset the join point by default anyway): you're correct. This is a bug, ORM join bugs are always of the highest priority and this will be fixed by tomorrow, #1925. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Setting the starting value of an autoincrement field?
Is there a way in the standard SQLA dialect support to set the starting value of an autoincrement field in the SQLA table definition? I can't see anything in the docs or code, but something like this is what I'm thinking: empnum = Column(sqla.Integer, primary_key = True, autoincrement = True, autoincrementstart = 1) which would make the first record have an empnum of 1 instead of 1. I'm learning that the autoincrement support across databases is a bit odd (what's up with Oracle??) and I expect if I want to do this I'll need to do some manual work, but figured I'd ask first. If no way to set the start at table definition time, what about a clean way to change the current value just after definition? -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Setting the starting value of an autoincrement field?
On Sep 20, 2010, at 11:00 PM, Russell Warren wrote:
Is there a way in the standard SQLA dialect support to set the
starting value of an autoincrement field in the SQLA table definition?
I can't see anything in the docs or code, but something like this is
what I'm thinking:
empnum = Column(sqla.Integer,
primary_key = True,
autoincrement = True,
autoincrementstart = 1)
Look at class sqlalchemy.schema.Sequence(name, start=None, increment=None,...)
http://www.sqlalchemy.org/docs/core/schema.html?highlight=sequence#sqlalchemy.schema.Sequence
Table('sometable', metadata,
Column('id', Integer, Sequence('some_id_seq'), primary_key=True)
)
http://www.sqlalchemy.org/docs/dialects/postgresql.html?highlight=sequence
Cheers,
M
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
