[sqlalchemy] Re: sqlite PK autoincrement not working when you do a composite PK?
On Saturday 14 June 2008 06:50:23 Russell Warren wrote: so far i have found these ways to hack somebeody else's source: a) inherit the class, replace whatever, use the new version - works if it is just you using the new-stuff b) complete replacement: import thatclass; thatclass.method = your-own-version c) partial hacks: inspect.get_source( that method); replace some lines in that with yours; compile; replace the method with the new version. this works if u have sources; if its just *.pyc, sorry. All good ways. I was planning on b), but I just couldn't (can't) locate the right replacement location underneath the SQLA classes I'm using (Session, Engine, Metadata, etc). Where the heck is the Compiler? it depends.. there is DefaultCompiler (called AnsiCompiler in 0.3) which is used when u do not have an engine yet (meta =Metadata()). and all dialects inherit from it. see dbcook/misc/aggregator/tests/convertertest.py for another hack for better visibility/str() of bindparams. also dbcook/misc/metadata/autoload is fiddling a bit with dialects. grep - and your very own eyes - are your friends. and of course trial+error... --~--~-~--~~~---~--~~ 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: sqlite PK autoincrement not working when you do a composite PK?
On Saturday 14 June 2008 06:28:58 Russell Warren wrote: if you'd like to specify a value generator for the columns, just use a ColumnDefault. Whatever function or SQL you like will be called if no value is present - its just in this case we can't rely upon SQLite's OID generation. Thanks - I'll look into that. I just have to figure out how to make ColumnDefault dialect dependent. I wouldn't favor a built in system of guessing within the sqlite dialect how to autoincrement a composite PK field without explicit user intervention. Why not? Is it really guessing when the table has been defined precisely within SQLA? If you have a Column that has been defined to be an Integer primary key that is supposed to autoincrement, and you are using sqlite... how could you be wrong? The worst case I can think of is if sqlite changes in the future to actually support it, in which case you'd either change the dialect or get an error. No? maybe the user should request it somehow. Here come extra dialect-preferences. e.g. Column may mantain an attribute extras4sqlite, eventualy containing a dict of sqlite-specific settings; same for postgres etc. Then the specific dialect can look the column and get his own extra-settings - if any. This gives explicitness, separation of concerns (generic vs specific), and flexibility together. And this can be applied to other objects, e.g. tables or whatever. i'm sure thre are things u can do with tables in postgress and u cannot do in sqlite. Once some feature/attribute is considered generic/unified, it is moved from those extra* settings into the usual place -- or vice versa if stops being generic. --~--~-~--~~~---~--~~ 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: Absurd operational error in SQLite
Michael Bayer wrote: oh. how are you getting it to join from soup- (album join vinyl) ? soup has a relation to album join vinyl and you're using query.join() ? it should be creating an aliased subquery for the right side of the join in that case. I thought 0.4 was able to do this; 0.5 definitely can. Attached is the example script from my previous thread, adapted to show the present issue. The setup is basically this: ratable_record = records.join( ratings, onclause=(ratings.c.id==records.c.id)) orm.mapper(RatableRecord, ratable_record, inherits=Soup, inherit_condition=(records.c.id==soup.c.id)) \malthe --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- example.tar.gz Description: GNU Zip compressed data
[sqlalchemy] Query Clone Issue
I realize I'm doing something hacky, but I'm wondering if this is the
expected behavior. The issue is that if I modify the modifier on a
UnaryExpression, even if I clone the Query ahead of time it modifies
other Query instances. See the following:
import datetime
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy import *
from sqlalchemy.sql import operators
from sqlalchemy.orm import sessionmaker
engine = create_engine('sqlite://')
Session = sessionmaker(bind=engine, autoflush=True, autocommit=False)
session = Session()
Base = declarative_base(engine=engine)
class Category(Base):
__tablename__ = 'foo_category'
id = Column('id', Integer, primary_key=True)
name = Column('name', String(50))
created_at = Column('created_at', DateTime, nullable=True,
onupdate=datetime.datetime.now)
def __repr__(self):
return self.name
Base.metadata.create_all()
session.add_all([Category(name='zzeek'),
Category(name='jek'),
Category(name='empty')])
# order ascending
c1 = session.query(Category).order_by(asc(Category.name))
assert [u'empty', u'jek', u'zzeek'] == [c.name for c in c1]
# clone the query and verify still asc
c2 = c1._clone()
assert [u'empty', u'jek', u'zzeek'] == [c.name for c in c2]
# reverse the order_by modifier on c1
c1._order_by[0].modifier = operators.desc_op
assert [u'zzeek', u'jek', u'empty'] == [c.name for c in c1]
# here's the problem, c2 is now modified
assert [u'zzeek', u'jek', u'empty'] == [c.name for c in c2]
Michael Trier
blog.michaeltrier.com
--~--~-~--~~~---~--~~
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: Query Clone Issue
the _clone() on query is a shallow copy, otherwise it would be a serious
performance hit for a query that takes several generative steps to build
up. So you'd have to assign query's _order_by to a copy of itself if you
want to modify it in place like that. you can probably use
visitors.cloned_traverse() on the element to copy it, then also copy the
list of elements as well (look at the source to query.order_by() to see
the idea).
empty wrote:
I realize I'm doing something hacky, but I'm wondering if this is the
expected behavior. The issue is that if I modify the modifier on a
UnaryExpression, even if I clone the Query ahead of time it modifies
other Query instances. See the following:
import datetime
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy import *
from sqlalchemy.sql import operators
from sqlalchemy.orm import sessionmaker
engine = create_engine('sqlite://')
Session = sessionmaker(bind=engine, autoflush=True, autocommit=False)
session = Session()
Base = declarative_base(engine=engine)
class Category(Base):
__tablename__ = 'foo_category'
id = Column('id', Integer, primary_key=True)
name = Column('name', String(50))
created_at = Column('created_at', DateTime, nullable=True,
onupdate=datetime.datetime.now)
def __repr__(self):
return self.name
Base.metadata.create_all()
session.add_all([Category(name='zzeek'),
Category(name='jek'),
Category(name='empty')])
# order ascending
c1 = session.query(Category).order_by(asc(Category.name))
assert [u'empty', u'jek', u'zzeek'] == [c.name for c in c1]
# clone the query and verify still asc
c2 = c1._clone()
assert [u'empty', u'jek', u'zzeek'] == [c.name for c in c2]
# reverse the order_by modifier on c1
c1._order_by[0].modifier = operators.desc_op
assert [u'zzeek', u'jek', u'empty'] == [c.name for c in c1]
# here's the problem, c2 is now modified
assert [u'zzeek', u'jek', u'empty'] == [c.name for c in c2]
Michael Trier
blog.michaeltrier.com
--~--~-~--~~~---~--~~
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: sqlite PK autoincrement not working when you do a composite PK?
Russell Warren wrote: Why not? Is it really guessing when the table has been defined precisely within SQLA? If you have a Column that has been defined to be an Integer primary key that is supposed to autoincrement, and you are using sqlite... how could you be wrong? autoincrement is very difficult to implement in application code in an atomic and high performing fashion. If we're not using what the DB engine provides natively, then the user has to pick the method he or she wishes to use, since each would have caveats the user needs to be aware of. I'm not opposed to having a catalog of id generator tools within the distro but as of yet nobody has offered any. A key philosophy of SQLA is that we don't make choices for the user without explicit statement. But at the same time the dialect is also abstracting out many of the annoying backend type differences. I thought that a big part of SQLA was going to be allowing the use of any back end. We abstract as much as is reasonably possible. But we also honor and make explicit the differences between those databases so that each backend can be used to its fullest potential. Another big philosophy of ours is to not pretend the database doesn't exist by forcing all the various vendors into the lowest denominator of functionality. Practices like that are what give object relational tools as well as RDBMS overall a bad name. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
