RE: [sqlalchemy] Possible bug with subqueryload
-Original Message- From: sqlalchemy@googlegroups.com [mailto:sqlalchemy@googlegroups.com] On Behalf Of Michael Bayer Sent: 27 September 2011 19:37 To: sqlalchemy@googlegroups.com Subject: Re: [sqlalchemy] Possible bug with subqueryload On Sep 27, 2011, at 1:16 PM, King Simon-NFHD78 wrote: Great, thanks a lot :-) I only discovered it in a toy application, and the workaround (including order_by on the query) is not a problem. In this toy application, I was also wondering if there existed a mechanism for doing some sort of lazy subqueryload. ie. I'm loading a collection of objects and I don't know ahead of time if I'm going to access a particular relationship (so I don't want to eagerload it). However, if I *do* access it, I'm going to access it on each object in the collection, so I'd like to load all the related objects in a single hit. It's just like a subqueryload, except it is only executed when the relationship is accessed for the first time. Is that a silly idea? Or perhaps it already exists and I've missed it. It actually exists in Hibernate, but not for us.We do sort of have the infrastructure in place to make it possible, i.e.the subqueryload right now prepares a Query object at query time that fires off during load time, with a mapper option it would need to stick it as some kind of memo in each InstanceState, it would be very tricky to implement.Keeping that state and keeping it plugged into the InstanceStates, then what if the loader was fired after many of the other states have been garbage collected, just a lot of corner cases to deal with. it can be handrolled of course, the general technique when you want to construct objects such that they appear loaded is to use attributes.set_commited_value() to set an attribute such that the ORM sees it as what was loaded from the database. an example of that is where we first introduced the subquery concept here: http://www.sqlalchemy.org/trac/wiki/UsageRecipes/DisjointEagerLoading Ah yes, set_committed_value is exactly the sort of thing I was looking for. Thanks a lot, Simon -- 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] DropTable if exists
Hi, Much less controversial question this time, I hope ;-) I have: class MyModel(Base) ... I want to do: engine = create_engine(...) engine.execute(DropTable(MyModel.__table__)) engine.execute(CreateTable(MyModel.__table__)) ...of course, this barfs the first time I run it as the table doesn't exist. I was looking for something like: engine.execute(DropTable(MyModel.__table__, if_exist=True)) what's the right way to do this? Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- 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] delcarative with autoload when you have no connection
On 27/09/2011 18:48, Michael Bayer wrote: (Note to readers: Chris and I hang out each year at Pycon. He's a great guy, so forgive the colloquial tone I take with him !) Likewise, I should point out I have huge amounts of respect for Mike, so if I'm grumbling, it's usually 'cos he's right ;-) - write unit tests for for you would have unit tests against your models being able to persist data to and from the database. touche ;-) (I guess I'm just obsessive about testing...) if you have two projects - one uses reflection to do everything, the other doesn't, those two projects are already going to be slightly different - except one will have this weird mymodel.prepare() call buried deep inside of it. With the recipe being something explicit, its easier to see that project B is doing things differently. touche again... - it is easier for us to support just the __mapper_cls__ argument rather than a full usage pattern. Why? How would the full usage pattern differ? Generally when I come up with a recipe to solve a problem in 5 minutes, its not ready to be a core feature.If it becomes the prominent way to do things, we would need to ensure that all other methods are de-emphasized, etc. I guess this is currently happening with declarative now, right? Out of .ext in 0.8? ;-) Declarative already has an attribute called __autoload__, which I yanked out of the docs.You can already say __table__ = Table(..., autoload=True), and __autoload__ was redundant and less-featured. Users who needed to reflect the Table, use declarative, but also needed to customize the Table a bit as described at http://www.sqlalchemy.org/docs/core/schema.html#overriding-reflected-columns Hmm, okay, but using the DeclarativeReflectedBase pattern doesn't prevent this, right? Also, just checking, are the following assumptions correct: - autoload doesn't build relationships yet? - I'll be able provide relationships and override column declarations on the declarative models when using the DeclarativeReflectedBase pattern? I can guarantee you users are already completely confused by the use case - my Engine isn't there yet ? I'm moderately opinionated on this; the default pattern should be that the engine isn't there when you're doing declarations. Most frameworks nowadays take the db connection string from a confict file, and that only gets parsed at app startup time, not at module global scope... Sure, it's nice for the trivial case just to hard-code a create_engine call at global scope, but I don't think it should be encouraged... supported here ? I can try to find you a big long email from a few months ago where someone was already totally confused about the Session docs, describing that you can say sessionmaker.configure(engine) instead of Session(bind=engine) - he was *totally* mystified by that whole thing and the purpose. Are you sure that wasn't from me? ;-) Very, very hard to describe convenience features, because they apply to certain use cases that most users don't have, and aren't sure they have when they first read the docs. Usage recipes make it a *ton* more clear that these are specific applications for specific problems. Meh, my experience is that usage recipes just push the problem to a different place: which pattern should I use?, Am I using the right one?, will this bite me later?, is this still up to date?... Also, a lot of apps that use reflection *can't* use this method - they have hundreds of tables and reflection is too slow. Yeah, that's where I'm at, hence only reflecting tables that are mapped declaratively, which the DeclarativeReflectedBase appears to offer, right? It'll only reflect tables for models that have been imported by the time 'prepare' is called, right? For them, we often advise reflect everything and pickle it into a serialized file, ...then you have to blow away the pickle when the schema changes, right? Or use an autogen tool that derives from reflection. Any of these you can recommend? This again is why the philosophy is - SQLAlchemy is building blocks. You must be prepared to provide a foundation for non-trivial applications, and you must understand how the essential components function. If you want everything SQLA can offer, you'll need to think of yourself as a software developer, not a button-pushing monkey, basically. But I like button pushing ;-) cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- 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] DropTable if exists
well the easiest is mytable.drop(engine, checkfirst=True). The check is not within the DropTable construct, which represents just the actual DROP TABLE statement.If you were using DropTable directly you'd call engine.has_table(tablename) first to check for it. On Sep 28, 2011, at 8:07 AM, Chris Withers wrote: Hi, Much less controversial question this time, I hope ;-) I have: class MyModel(Base) ... I want to do: engine = create_engine(...) engine.execute(DropTable(MyModel.__table__)) engine.execute(CreateTable(MyModel.__table__)) ...of course, this barfs the first time I run it as the table doesn't exist. I was looking for something like: engine.execute(DropTable(MyModel.__table__, if_exist=True)) what's the right way to do this? Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- 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.
Re: [sqlalchemy] DropTable if exists
On 28/09/2011 13:19, Michael Bayer wrote:
well the easiest is mytable.drop(engine, checkfirst=True).
The check is not within the DropTable construct, which represents just the
actual DROP TABLE statement.If you were using DropTable directly you'd call
engine.has_table(tablename) first to check for it.
Hmm, but both mysql and postgres (I suspect others do too, but I haven't
checked) have DROP TABLE IF EXISTS statements so you don't need to do
any checking. That feels like it should be supported by the DropTable
construct, what am I missing?
Anyway, in an effort to get this, I tried:
File ...model.py,
line 46, in module
engine.execute('drop table if exists %s', table.name)
File sqlalchemy/engine/base.py,
line 2285, in execute
return connection.execute(statement, *multiparams, **params)
File sqlalchemy/engine/base.py,
line 1399, in execute
params)
File sqlalchemy/engine/base.py,
line 1576, in _execute_text
statement, parameters
File sqlalchemy/engine/base.py,
line 1640, in _execute_context
context)
File sqlalchemy/engine/base.py,
line 1633, in _execute_context
context)
File sqlalchemy/engine/default.py,
line 325, in do_execute
cursor.execute(statement, parameters)
sqlalchemy.exc.ProgrammingError: (ProgrammingError) syntax error at or
near E'table_name'
LINE 1: drop table if exists E'table_name'
Where's that E coming from?
cheers,
Chris
--
Simplistix - Content Management, Batch Processing Python Consulting
- http://www.simplistix.co.uk
--
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] DropTable if exists
On Sep 28, 2011, at 8:32 AM, Chris Withers wrote:
On 28/09/2011 13:19, Michael Bayer wrote:
well the easiest is mytable.drop(engine, checkfirst=True).
The check is not within the DropTable construct, which represents just the
actual DROP TABLE statement.If you were using DropTable directly you'd
call engine.has_table(tablename) first to check for it.
Hmm, but both mysql and postgres (I suspect others do too, but I haven't
checked) have DROP TABLE IF EXISTS statements so you don't need to do any
checking. That feels like it should be supported by the DropTable construct,
what am I missing?
oh, that. Right you'd need to use @compiles to enhance a new subclass of
DropTable to do that, as SQLA's compiler doesn't have the IF EXISTS feature
present at the moment (it could be added).
The E is how psycopg2 formats the %s - table.name parameter in your
statement for certain versions of Postgresql. I don't know what it actually
means but if you watch your PG logs you'll see it's used for all bound
parameters.
Anyway, in an effort to get this, I tried:
File ...model.py,
line 46, in module
engine.execute('drop table if exists %s', table.name)
File sqlalchemy/engine/base.py,
line 2285, in execute
return connection.execute(statement, *multiparams, **params)
File sqlalchemy/engine/base.py,
line 1399, in execute
params)
File sqlalchemy/engine/base.py,
line 1576, in _execute_text
statement, parameters
File sqlalchemy/engine/base.py,
line 1640, in _execute_context
context)
File sqlalchemy/engine/base.py,
line 1633, in _execute_context
context)
File sqlalchemy/engine/default.py,
line 325, in do_execute
cursor.execute(statement, parameters)
sqlalchemy.exc.ProgrammingError: (ProgrammingError) syntax error at or
near E'table_name'
LINE 1: drop table if exists E'table_name'
Where's that E coming from?
cheers,
Chris
--
Simplistix - Content Management, Batch Processing Python Consulting
- http://www.simplistix.co.uk
--
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] Possible bug with subqueryload
that mapper.order_by thing is fixed in 0.7.3/0.6.9 tip. -- 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] DropTable if exists
On 28/09/2011 14:09, Michael Bayer wrote:
Hmm, but both mysql and postgres (I suspect others do too, but I haven't checked) have
DROP TABLE IF EXISTS statements so you don't need to do any checking. That
feels like it should be supported by the DropTable construct, what am I missing?
oh, that. Right you'd need to use @compiles to enhance a new subclass of DropTable to do
that, as SQLA's compiler doesn't have the IF EXISTS feature present at the
moment (it could be added).
I guess it probably should, I think that one could legitimately be in
sqlalchemy itself ;-)
The E is how psycopg2 formats the %s - table.name parameter in your
statement for certain versions of Postgresql. I don't know what it actually means but if
you watch your PG logs you'll see it's used for all bound parameters.
Hmm, any ideas why it'd cause a syntax error here?
I'm doing engine.execute('drop table if exists %s' + table.name) in the
meantime, which just feels icky...
Chris
--
Simplistix - Content Management, Batch Processing Python Consulting
- http://www.simplistix.co.uk
--
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] Possible bug with subqueryload
On Wed, Sep 28, 2011 at 2:15 PM, Michael Bayer mike...@zzzcomputing.comwrote: that mapper.order_by thing is fixed in 0.7.3/0.6.9 tip. Brilliant - thanks again for all the time you put in to SA and this group, Simon -- 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] DropTable if exists
On Sep 28, 2011, at 9:47 AM, Chris Withers wrote:
On 28/09/2011 14:09, Michael Bayer wrote:
Hmm, but both mysql and postgres (I suspect others do too, but I haven't
checked) have DROP TABLE IF EXISTS statements so you don't need to do any
checking. That feels like it should be supported by the DropTable
construct, what am I missing?
oh, that. Right you'd need to use @compiles to enhance a new subclass of
DropTable to do that, as SQLA's compiler doesn't have the IF EXISTS
feature present at the moment (it could be added).
I guess it probably should, I think that one could legitimately be in
sqlalchemy itself ;-)
The E is how psycopg2 formats the %s - table.name parameter in your
statement for certain versions of Postgresql. I don't know what it actually
means but if you watch your PG logs you'll see it's used for all bound
parameters.
Hmm, any ideas why it'd cause a syntax error here?
I'm doing engine.execute('drop table if exists %s' + table.name) in the
meantime, which just feels icky...
oh probably it doesn't like table name as a bound parameter.
Chris
--
Simplistix - Content Management, Batch Processing Python Consulting
- http://www.simplistix.co.uk
--
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.
Re: [sqlalchemy] Validation of new objects before committing
On Sep 28, 2011, at 10:08 AM, Kirk Strauser wrote: I get what you're saying, truly, and agree with the underlying argument: SQLA is an ORM, not a data validator, template parser, or cheese grater. But I would contend that the kind of validations I'm proposing would operate on the level SQLA occupies. What I had in mind wouldn't answer the question does this column contain the correctly spelled name of a Pantone color?, but is the data in this column capable of being stored in the underlying database? For instance, if Model.foo is Column(Integer), and the client app sets it to creqcrq, then most databases (ignoring SQLite for the moment) will balk at insertion time. Similarly, PostgreSQL won't let you store value in Column(String(1)). If my model has already defined that column as a String(1), it'd be convenient if I could ask SQLA if the object I've just created can even be stored. SQLA is very loathe to duplicate what the DBAPI and/or database already does. These use cases are all already covered, the issue here is wanting those validations to be duplicated under the specific use case that invalid values should be skipped, instead of halting the operation.This already cuts down the usefulness of such a feature to a small percentage of projects. The scope of column-based validations we can do is limited. nullable is simple, sure. Also, there are type-based validations, fine, string, numeric, integer, dates, including length of strings. If someone throws on postgresql.INET, not really, unless the contract of TypeEngine objects is extended such that they *all* get in-python validation functions. Which is really, really redundant, as DBAPIs do that most of the time. Very heavyhanded for very little use - we definitely don't want these validations turned on all the time as they'd kill performance unnecessarily. String length in particular, we have to deal with unicode conversions before checking length, some databases store unicode as number of chars others as number of encoded bytes, it's complicated, and entirely redundant vs. what the database already does. Other validations that can be derived from schema include CheckConstraint. It contains a SQL expression - if it's a string, we can't test it without going to the database. If it's derived from a SQL expression construct, we can use the techniques in orm.evaluator to run an extremely limited subset of that expression, it would be awkward, it would fail all the time due to all kinds of database-specfic SQL functions we don't have a translation for. To get Python-side validation here, the user probably has to supply an in-python validation function separately from the constraint itself (and we have hooks for that). Another one, UniqueConstraint. How do we check that in Python without hitting the DB ? not really possible. Same for ForeignKeyConstraint. I didn't mention this last time but we do have almost everything you need to do validations except for the validation functionality itself - the @validates decorator and its more generalized version, the attribute set event, receives the attribute, the value, all you need to do is take a look at the Column passed in, associated with the incoming attribute. From there you can look at nullable, and maybe check within five or six possible types that are built-in. It still seems like a trivial amount of code for anyone to do for a specific subset of validations - to do it for a very wide range of validations, as a built-in feature demands, its an enormous job which would require a ton of testing and would almost never be used as it would be an unnecessary performance hit for a job the database already does much better. SQLAlchemy itself really cannot implement such a feature in any reasonable way, it would have a huge amount of holes in it. It is definitely best as a third party project, the hooks are there. -- 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] Re: Weird error using SQLAlchemy 0.7.2, MySQL, Python3, SqlSoup and relate
I'm keeping a project that does pretty much the same as SQLSoup but
also does automatic relationship and backref mapping.
It also relies on the new Declarative Base and it doesn't rely on
anything from SQLSoup, so when Soup gets discontinued, SQLasagna will
go on :)
You can see the code, fork it and help developing it on:
https://github.com/ygbr/SQLasagna
Thanks.
On Aug 18, 7:44 am, Ygor Lemos opti...@gmail.com wrote:
If anybody else is experiencing this same problem, I have opened a Bug
Request @ SQLA Trac and you can follow it through here:
http://www.sqlalchemy.org/trac/ticket/2260
On Aug 18, 1:56 am, Ygor Lemos opti...@gmail.com wrote:
Oh, sorry about that, I copied from a previous declaration I've been
testing using Table() objects... I did remove the ,'s and all worked
fine... The relationships are normal both in py3k and py2 with the
latest SQLA. So the problem really lies on the relate() method of
SqlSoup.
Thanks again for your time.
On Aug 18, 1:25 am, Michael Bayer mike...@zzzcomputing.com wrote:
On Aug 17, 2011, at 10:15 PM, Ygor Lemos wrote:
I tried the following for manually mapping the tables:
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
from sqlalchemy import *
from sqlalchemy import dialects
from sqlalchemy import sql
from sqlalchemy.orm import *
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.sql.expression import *
engine = create_engine(mysql+oursql://:XXX@XX/
XXX?charset=utf8use_unicode=Trueautoping=True, echo=True)
metadata = MetaData(engine)
Base = declarative_base()
class User(Base):
__tablename__ = users
id = Column(Integer, primary_key=True),
login = Column(String(25)),
name = Column(String(50)),
passwd = Column(String(100)),
email = Column(String(100)),
atype = Column(String(50)),
active = Column(Boolean),
customers_id = Column('customers_id', Integer,
ForeignKey('customers.id')),
all of those commas at the end of each line results in the class having a
tuple called id in it, rather than a set of attributes id, login,
name etc which declarative can interpret as mapping directives.
--
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] Re: Validation of new objects before committing
while we are on the subject, i'd like to ask a question if i'm doing
it right or wrong.
i have created a class called Validation with a method called is_valid
and I have mixed it in my SQLAlchemy models. all of my models has an
attribute called validation that consists of model's attributes that
must be valid. it's like this:
class User(DeclarativeBase, Validation):
validation = {
'username': [formencode.validations.NotEmpty],
'email': [formencode.validations.NotEmpty,
formencode.validations.Email]
}
# model definition here..
and then in my controller i check if model_instance.is_valid() and
then add it to my db. if it's not valid, i render the previous page.
let me know if you guys have any recommendations.
On 27 Eylül, 21:56, Michael Bayer mike...@zzzcomputing.com wrote:
On Sep 27, 2011, at 1:57 PM, Kirk Strauser wrote:
Does SA natively support (or is there a module on PyPI that supports)
client-side validation of SQLAlchemy objects? For example, I have this
declarative class:
class ImportedPayment(Base):
__tablename__ = 'importedpayment'
__table_args = {'schema': 'public'}
paymentid = Column(Integer, primary_key=True)
externalid = Column(String(16), nullable=False)
line = Column(Integer, nullable=False)
invoicestatus = Column(String(32), nullable=False)
quantity = Column(Numeric(scale=2), nullable=False)
rate = Column(Numeric(scale=2), nullable=False)
Is there an easy way to do this?
OK so the aspect you're looking for here is to define those validations just
once, this is easy enough through a recipe like this:
def notnull(key):
def validate(obj):
if getattr(obj, key) is None:
return Object %s key %s is None % (obj, key)
else:
return False
return validate
_validators = {}
def get_validators(someobject):
mapper = object_mapper(someobject)
if mapper in _validators:
return _validators[mapper]
_validators[mapper] = v = []
for prop in mapper.iterate_properties():
if hasattr(prop, columns):
col = prop.columns[0]
if not col.nullable:
v.append(notnull(prop.key))
# ... ad nauesum, i.e.
# if something else about the column:
# v.append(some other kind of validation function)
return v
def validate(someobject):
for validator in get_validators(someobject):
msg = validator()
if msg:
log(msg)
# etc., i.e.
# alert_the_authorities()
If not, why?
So the theme for today is why does SQLA have recipes, basically when we can
provide the core fragment of a feature but not a fully polished, documented,
tested, packaged result, something that can just as easily be delivered as a
small batch of customizable source code gets the job done pretty well, and
would be better suited as a separate library if fully fleshed out.
The above recipe lacks a lot of features one might want, such as customizable
ways of defining the validation failure, behavior on the receipt of a failed
validation, etc. A full blown validation library might use the idea
above but expand upon it in a much bigger way. I've had other ad-hoc
validation use cases that wouldn't work with the above structure, instead
needing a slightly different structure, so having a small thing just as code
for now is more flexible than a built in feature that only handles a small
subset of use cases.
And if the answer to that is because you haven't written it yet, would
anyone be interested in using it if I were to create such a thing?
You might want to check around if similar things don't exist already, I did
findhttp://pypi.python.org/pypi/SAValidation/andhttp://pypi.python.org/pypi/sqlalchemy_elixir_validations/for
example, there might be features there that are of use. But by all means,
produce a better validation library for SQLAlchemy, the more the merrier and
I'd love to see more.
--
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] Validation of new objects before committing
On Sep 28, 2011, at 9:45 AM, Michael Bayer wrote: Also, there are type-based validations, fine, string, numeric, integer, dates, including length of strings. If someone throws on postgresql.INET, not really, unless the contract of TypeEngine objects is extended such that they *all* get in-python validation functions. Which is really, really redundant, as DBAPIs do that most of the time. Very heavyhanded for very little use - we definitely don't want these validations turned on all the time as they'd kill performance unnecessarily. String length in particular, we have to deal with unicode conversions before checking length, some databases store unicode as number of chars others as number of encoded bytes, it's complicated, and entirely redundant vs. what the database already does. OK, you've convinced me. I hadn't taken those cases into consideration; they don't come up much in the stuff I'm working with. For the record, though (in case anyone ever Googles this and wonders what I was thinking), I never thought of this as a mandatory behavior but as something that would be there if you wanted to use it, like: from sqlalchemy import getvalidationerrors newobj = MyClass(column1='foo', column2='bar') for error in getvalidationerrors(newobj): [...] Anyway, thanks for the pointers to a workable ad-hoc approach. - Kirk -- 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] DropTable if exists
On Wed, Sep 28, 2011 at 8:56 AM, Michael Bayer mike...@zzzcomputing.comwrote:
On Sep 28, 2011, at 9:47 AM, Chris Withers wrote:
On 28/09/2011 14:09, Michael Bayer wrote:
I'm doing engine.execute('drop table if exists %s' + table.name) in the
meantime, which just feels icky...
oh probably it doesn't like table name as a bound parameter.
Don't you mean 'drop table if exists %s' % table.name not + table.name
if table.name is mytable wouldn't using + generate drop table if exists
%smytable?
--
Mike
--
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.
