For me, starting off with SQLAlchemy, "metadata" immediately made
sense, because I'd heard and used the term before in the context of
databases. After using SQLAlchemy for a while it seems like metadata
is pretty well true to it's name. The word "catalog", on the other
hand, means nothing to me in a database context until you tell me. I
guess I wasn't a total database beginner, but I think real beginners
are likely to know what the term "metadata" means (i.e., "data about
data" is pretty simple and memorable).
I also recall using "metadata.engine" somewhere. That seems to make (a
little) more sense than "catalog.engine".
I have no preference for "engine" versus "datasource". I do agree that
datasource would be better for a beginner (not that that should be the
only criteria).
My 2 cents.
Steve
The more I learned SQLAlchemy, the more I think my initial
impression of what it meant, in a SQLAlechemy context, was pretty
right.
On Jul 26, 7:45 pm, jason kirtland <[EMAIL PROTECTED]> wrote:
> With 0.4 almost upon us, we're coming down to the wire for big changes
> getting in- and some things are kind of "now or never".
>
> I've found myself explaining engines and metadata with some particular
> language lately, and I wondered, what would it look like to just put
> that terminology in the names themselves? This is the last opportunity
> for terminology changes for a while, so I offer this up for discussion.
>
> So here's what I was thinking:
>
> datasource = create_datasource('posgresql:///test')
> connection = datasource.connect()
>
> catalog = Catalog()
> Table('foo', catalog, autoload=True)
> catalog.bind = datasource
>
> catalog.bind = 'sqlite:///'
>
> Engines would be DataSources, and MetaData would be Catalogs.
>
> I like the datasource name over engine because, from a user perspective,
> engines don't "go"- there's no moving parts. Most of the time in
> application code I think about these engines as URIs anyhow: Where is
> this pointing? What database is that bound to? Which DB is that coming
> from? The fact that it has a dialect, pool, etc., is just a given and
> unimportant to me on the line. I just think about what I'm connecting
> to or have connected. This is my mental translation:
>
> # see
> engine.connect()
> # think
> 'mysql:///geocoding'.connnect()
>
> ...and I think a name change would help smooth out questions like 'how
> do I organize my engine/engines in my code'. It feels natural to me as
> well coming from other orms and pooling libraries.
>
> I've been describing the metadata as a catalog for a bit now- "a catalog
> of tables available in the database." There's something about the name
> MetaData which, to me, is simultaneously vague and final. Like it's
> very important, I don't really know what it does, and I should probably
> only have one. In reality of course they're quite disposable and flexible.
>
> So there you have it. I'm not married to this proposal by *any* means.
> The ideas gelled in my brain during the SQLAlchemy tutorial at OSCON,
> and this seems like the last opportunity to deeply question and
> reconsider what we have before a new generation of users takes on
> SQLAlchemy.
>
> -j
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
