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.
