Re: [sqlalchemy] Re: porting GeoAlchemy to 0.7
On Thu, Jun 9, 2011 at 7:21 PM, Michael Bayer wrote: > > On Jun 9, 2011, at 12:37 PM, Eric Lemoine wrote: > >> On Thu, Jun 9, 2011 at 6:28 PM, Michael Bayer >> wrote: >>> >>> >>> That's the default adaption provided by TypeEngine.adapt(). Provide your >>> own adapt() that does what's needed. For examples see Interval, Enum. >> >> Ok, I'll take a look at adapt(). Note that our Geometry type isn't >> specific to Oracle though. > > When you get it going, if you can show us what you're doing, we can create a > prototypical version of your type, demonstrating the kind of "add new > arguments per dialect" functionality it has, and add it to our test suite, > to ensure those usage patterns don't break. SQLAlchemy usually uses > distinct type classes per backend to handle backend-specific arguments, so > your approach of allowing DB-specific keyword arguments to a single type, > which while entirely appropriate in your case, isn't a pattern we test for at > the moment. See the attached patch. Please tell if I should create a Trac ticket and attach my patch to it. Cheers, -- Eric Lemoine Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac, Cedex Tel : 00 33 4 79 44 44 96 Mail : eric.lemo...@camptocamp.com http://www.camptocamp.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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en. diff --git a/test/sql/test_types.py b/test/sql/test_types.py --- a/test/sql/test_types.py +++ b/test/sql/test_types.py @@ -273,6 +273,18 @@ Float().dialect_impl(pg).__class__ ) +def test_user_defined_dialect_specific_args(self): +class MyType(types.UserDefinedType): +def __init__(self, foo='foo', **kwargs): +self.foo = foo +self.dialect_specific_args = kwargs +def adapt(self, cls): +return cls(foo=self.foo, **self.dialect_specific_args) +t = MyType(bar='bar') +a = t.dialect_impl(testing.db.dialect) +eq_(a.foo, 'foo') +eq_(a.dialect_specific_args['bar'], 'bar') + @testing.provide_metadata def test_type_coerce(self): """test ad-hoc usage of custom types with type_coerce()."""
Re: [sqlalchemy] Sqlite date field
On Jun 19, 2011, at 10:06 AM, Michael Bayer wrote: > Look into using a TypeDecorator around String. > > process_bind_param() and process_result_value() would coerce the data between > string / Python date. > > http://www.sqlalchemy.org/docs/core/types.html#augmenting-existing-types > some examples: > http://www.sqlalchemy.org/docs/core/types.html#typedecorator-recipes Michael, Thanks for the tip and the examples. I got a TypeDecorator working. My initial attempts failed as I was trying to descent from a Date class or use impl=types.Date. When I switched to String, things worked better. Mark -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Joining queries with column concatenation.
Hi,
another day and another challenge :).
Somehow SQLAlchemy has a problem determining what to join when using
concatenation of columns.
this: session.query(Locality.name, Street.name).join(Street.locality)
properly joins:
FROM street JOIN locality ON street."localityId" = locality."Id"
but this: session.query(Locality.name + ' ' +
Street.name).join(Street.locality)
does: FROM street, locality JOIN locality ON street."localityId" =
locality."Id"
The second one can be fixed with joining on the backref of
Stret.locality,
but maybe SQLAlchemy could work it out on its own?
This is the code (copy at http://ideone.com/wWvT5 ):
# Fails with Python-2.7.0 and SQLAlchemy-0.7.1
import sqlalchemy
import sqlalchemy.ext.declarative
import pprint
Base = sqlalchemy.ext.declarative.declarative_base(mapper =
sqlalchemy.orm.mapper)
engine = sqlalchemy.create_engine('sqlite:///:memory:', echo = True)
session = sqlalchemy.orm.scoped_session(
sqlalchemy.orm.sessionmaker(
bind = engine,
autocommit = False,
)
)
Base.metadata.bind = engine
class Locality(Base):
Id = sqlalchemy.Column( sqlalchemy.types.Integer, primary_key =
True, autoincrement = True)
__tablename__ = 'locality'
name = sqlalchemy.Column( sqlalchemy.types.String(128), nullable =
False)
class Street(Base):
Id = sqlalchemy.Column(sqlalchemy.types.Integer, primary_key = True)
__tablename__ = 'street'
name = sqlalchemy.Column( sqlalchemy.types.String(128), nullable =
False)
localityId = sqlalchemy.Column(sqlalchemy.types.Integer,
sqlalchemy.ForeignKey(Locality.Id))
locality = sqlalchemy.orm.relation(Locality, primaryjoin =
localityId == Locality.Id)
Base.metadata.create_all()
sp = Locality(name = 'Southpark')
sv = Locality(name = 'Smallville')
session.add(sp)
session.add(sv)
session.add(Street(name = 'sp1', locality = sp))
session.add(Street(name = 'sp2', locality = sp))
session.add(Street(name = 'sv1', locality = sv))
session.add(Street(name = 'sv2', locality = sv))
#q = session.query(Street.name + ' ' + Locality.name)
# the above works
#q = session.query(Locality.name, Street.name)
# the above works
q = session.query(Locality.name + ' ' + Street.name)
# the above causes:
# sqlite: sqlalchemy.exc.OperationalError: (OperationalError) ambiguous
column name: locality.name u'SELECT locality.name || ? || street.name AS
anon_1 \nFROM street, locality JOIN locality ON street."localityId" =
locality."Id" \nWHERE locality.name = ?' (', ', 'Southpark')
# postgresql: sqlalchemy.exc.ProgrammingError: (ProgrammingError) table
name "locality" specified more than once 'SELECT locality.name ||
%(name_1)s || street.name AS anon_1 \nFROM street, locality JOIN
locality ON street."localityId" = locality."Id" \nWHERE locality.name =
%(name_2)s' {'name_2': 'Southpark', 'name_1': ' '}
q = q.join(
Street.locality
).filter(
Locality.name == 'Southpark'
)
pprint.pprint(
q.all(),
indent = 2
)
regards,
Filip Zyzniewski
Tefnet
--
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
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Re: Conditional insert in one transaction
On Jun 18, 2011, at 4:32 PM, Eric Ongerth wrote: > Just curious and learning here -- There are two separate issues here, > aren't there? (1.) Atomicity of the transaction, taken care of by the > above discussion, and (2.) what if there was a need to have it be not > only atomic but consume as little time as possible between the read > and write, let's say for financial purposes? Right, so the "executing two statements at once instead of two statements" thing in this kind of case is a fleeting optimization. That is, its a micro optimization that is easily nullified by the surrounding context. Such as, if the way the app works in reality is that the row already exists 95% of the time, the optimization saves negligible time. Or if it's trivial to just pre-insert the rows in question, or a whole selection of 100 rows can be selected at once and just the ones that aren't present can be INSERTed in one multi-row statement, would provide even better performance. Taking a SELECT then an INSERT and making the choice to turn it into a non-ORM, single statement, database-specific call is something you'd do once the app is up and running, and the separate SELECT/INSERT pair has been observed to be a definite bottleneck with no feasible workaround.I.e. a non-premature optimization. -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Sqlite date field
Look into using a TypeDecorator around String. process_bind_param() and process_result_value() would coerce the data between string / Python date. http://www.sqlalchemy.org/docs/core/types.html#augmenting-existing-types some examples: http://www.sqlalchemy.org/docs/core/types.html#typedecorator-recipes On Jun 18, 2011, at 9:50 PM, Mark Erbaugh wrote: > I have a legacy database where dates are stored in the format mm/dd/ > (i.e. 06/18/2011). Is it possible to adapte the Sqlalchemy DATE() type to > use this format? If not, is is possible to create a new class to handle this > format? > > Thanks, > Mark > > -- > 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 > 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 sqlalchemy@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.
