[sqlalchemy] Re: a renaming proposal
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: a renaming proposal
> > btw around probing dbcook on 0.4, i got some sort of statistical
> > idea of what is used often, some in a frightening repeatable
> > pattern:
> >
> > from sqlalchemy import *
> > db = create_engine('url')
> > meta = MetaData(db)
> >
> > and just then all else follows... in 90% of my files.
> > i can make some module sqlalchemy4lazy.py that contains above...
> >
> > can the Catalog() construct from url directly? one line less...
>
> Current metadata can do that.
yeah... if it could relay all other kwargs to the
connect/create_engine too...
e.g. meta = MetaData( url, echo=True, whatever=...)
and no mentioning of create_engine() - for lazys and newbies.
Right now it accepts any kwarg and then ignores it.
Than would be one less arguable term (engine) in mass use ;-)
--~--~-~--~~~---~--~~
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: a renaming proposal
On 7/27/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> On Friday 27 July 2007 21:26:51 jason kirtland wrote:
> > svilen wrote:
> > > Anyway it may depend which audience are u targeting with these
> > > names - those who never seen an API or those for which names are
> > > important only to associate them with a
> > > library/version/use-case... both extremes are equaly
> > > uninteresting imo.
> >
> > I came around to thinking about these names by looking at the
> > tutorial, presenting and being presented to. The engine and
> > metadata have the honor of being the first things that anyone
> > evaluating SQLAlchemy is exposed to. Right after that, it's all
> > tables, columns, results, and similar familiar territory.
> >
> > So the audience I had in mind is really everyone new to the
> > project, at any level- a nebulous target, and more marketing than
> > technical. My thinking (which is not all that sophisticated on
> > this) is simply, "Is there a pain point here for first-timers?
> > Would a tweak increase adoption?" It's also influenced a bit by my
> > own experience, I recall hitting a little speed bump there myself.
>
> i see what u say. for me it would not matter that much anyway if it
> was named XXYZiL, as long its easy to remember and type.
> so Catalog is okay. more or less, it means (SA) what it is (real
> world).
> Datasource...
>
> btw around probing dbcook on 0.4, i got some sort of statistical idea
> of what is used often, some in a frightening repeatable pattern:
>
> from sqlalchemy import *
> db = create_engine('url')
> meta = MetaData(db)
>
> and just then all else follows... in 90% of my files.
> i can make some module sqlalchemy4lazy.py that contains above...
>
> can the Catalog() construct from url directly? one line less...
>
> also think about nice short variablename for Catalog() (docs etc)
> cat = Catalog( url)
Current metadata can do that.
--
Gaëtan de Menten
http://openhex.org
--~--~-~--~~~---~--~~
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: a renaming proposal
On Friday 27 July 2007 21:26:51 jason kirtland wrote:
> svilen wrote:
> > Anyway it may depend which audience are u targeting with these
> > names - those who never seen an API or those for which names are
> > important only to associate them with a
> > library/version/use-case... both extremes are equaly
> > uninteresting imo.
>
> I came around to thinking about these names by looking at the
> tutorial, presenting and being presented to. The engine and
> metadata have the honor of being the first things that anyone
> evaluating SQLAlchemy is exposed to. Right after that, it's all
> tables, columns, results, and similar familiar territory.
>
> So the audience I had in mind is really everyone new to the
> project, at any level- a nebulous target, and more marketing than
> technical. My thinking (which is not all that sophisticated on
> this) is simply, "Is there a pain point here for first-timers?
> Would a tweak increase adoption?" It's also influenced a bit by my
> own experience, I recall hitting a little speed bump there myself.
i see what u say. for me it would not matter that much anyway if it
was named XXYZiL, as long its easy to remember and type.
so Catalog is okay. more or less, it means (SA) what it is (real
world).
Datasource...
btw around probing dbcook on 0.4, i got some sort of statistical idea
of what is used often, some in a frightening repeatable pattern:
from sqlalchemy import *
db = create_engine('url')
meta = MetaData(db)
and just then all else follows... in 90% of my files.
i can make some module sqlalchemy4lazy.py that contains above...
can the Catalog() construct from url directly? one line less...
also think about nice short variablename for Catalog() (docs etc)
cat = Catalog( url)
people = Table( cat, 'people',...)
--~--~-~--~~~---~--~~
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: a renaming proposal
im more in favor of "Datasource", less so for Catalog. i still think "Catalog" is vague, MetaData is a well known word and we can just describe it really carefully as "MetaData is a catalog of tables.". if you read fowlers book it *is* exactly what we are using it as, its information about your tables and columns stored programmatically. i dont think people are walking away from SA because the word "MetaData" is too imposing, its how its combined with 5 other concepts that arent presented cleanly enough that would cause that to happen. I think there are a lot of things about the docs that do chase users away, probably the biggest is the two separate worlds of SQL expressions and Query objects. On Jul 27, 2007, at 2:26 PM, jason kirtland wrote: > > svilen wrote: >> Anyway it may depend which audience are u targeting with these >> names - those who never seen an API or those for which names are >> important only to associate them with a >> library/version/use-case... both extremes are equaly >> uninteresting imo. > > I came around to thinking about these names by looking at the > tutorial, presenting and being presented to. The engine and > metadata have the honor of being the first things that anyone > evaluating SQLAlchemy is exposed to. Right after that, it's all > tables, columns, results, and similar familiar territory. > > So the audience I had in mind is really everyone new to the > project, at any level- a nebulous target, and more marketing than > technical. My thinking (which is not all that sophisticated on > this) is simply, "Is there a pain point here for first-timers? > Would a tweak increase adoption?" It's also influenced a bit by my > own experience, I recall hitting a little speed bump there myself. > > > > --~--~-~--~~~---~--~~ 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: a renaming proposal
svilen wrote: > Anyway it may depend which audience are u targeting with these > names - those who never seen an API or those for which names are > important only to associate them with a > library/version/use-case... both extremes are equaly > uninteresting imo. I came around to thinking about these names by looking at the tutorial, presenting and being presented to. The engine and metadata have the honor of being the first things that anyone evaluating SQLAlchemy is exposed to. Right after that, it's all tables, columns, results, and similar familiar territory. So the audience I had in mind is really everyone new to the project, at any level- a nebulous target, and more marketing than technical. My thinking (which is not all that sophisticated on this) is simply, "Is there a pain point here for first-timers? Would a tweak increase adoption?" It's also influenced a bit by my own experience, I recall hitting a little speed bump there myself. --~--~-~--~~~---~--~~ 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: a renaming proposal
Marco wrote: > > svilen ha scritto: > >> Anyway it may depend which audience are u targeting with these >> names - those who never seen an API or those for which names >> are important only to associate them with a >> library/version/use-case... both extremes are equaly >> uninteresting imo. >> > > I think targeting those who read Fowler's book (or really should) > is good enough :-) > MetaData is not ambiguous. > > One of the things I liked at first about SA is that, having just > bought the book, it had several of the book's patterns with the > same names. I agree that hitting familiar pattern names is good, but I'm not sure I agree that our MetaData class is Fowler's Metadata pattern, or a profitable entry point for walking through the SQLAlchemy metadata mapping strategy: mapper(Class, table) is the magic, and no MetaData in sight. --~--~-~--~~~---~--~~ 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: a renaming proposal
On 7/26/07, 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 think this is an improvement. I'm not sure if it's enough of one to
change everything, but I do think it makes things a bit more clear.
--~--~-~--~~~---~--~~
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: a renaming proposal
On Friday 27 July 2007 18:14:48 Michael Bayer wrote: > On Jul 27, 2007, at 6:29 AM, avdd wrote: > > On Jul 27, 9:45 am, jason kirtland <[EMAIL PROTECTED]> wrote: > >> This is the last opportunity > >> for terminology changes for a while, so I offer this up for > >> discussion. > > > > Does anyone else think "orm.relation" is wrong? Perhaps > > "relationship" if you must have a noun, or "relates_to", etc, but > > "relation" could cement the popular misunderstanding of > > "relational database". > > "relation" is wrongish because it conflicts with Codd's term > "relation". > > However, I have pored over SQL and relational articles to see what > word they use when they want to describe a table A that joins to > table B. > > and they always say: "relationship". > > If you look up "relation" and "relationship" in the dictionary, > *they mean the same thing*. > > somehow naming it "relationship" feels weird (though we can go with > that if we want). "relates_to", probably more accurate..but the > kinds of words we've been using in "properties" (and generally) are > nouns. Elixir is the one using the "verb/preposition" style. well, there are relations (interdependencies if u want) between the tables in SQL, AND there are relations (interdependencies) between objects in OOP, AND there are relations (interdependencies) between things in real world. Call them whatever, they mean same thing, but in different context/"world". so i think "relation" is okay, as long the context of usage is obvious. sql.relation vs orm.relation vs whatever.relation. Also, the verb-ish way (relates_to) adds some directional scent, which may or may not be intended/needed... i have different trouble with orm.relation, mostly that i'm mixing it with a collection in some cases, when it is just a way to implement a collection. --~--~-~--~~~---~--~~ 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: a renaming proposal
> So here's what I was thinking:
>
> datasource = create_datasource('posgresql:///test')
> connection = datasource.connect()
+0 -- I think it's moderately better than engine but for me, not
enough to want to change, though I wouldn't mind seeing it changed.
> catalog = Catalog()
> Table('foo', catalog, autoload=True)
> catalog.bind = datasource
>
> catalog.bind = 'sqlite:///'
+1
Catalog is, I think, the name we were all trying to come up with back
when metadata first appeared. Really makes it clear what the function
of the object is. Very nice.
JP
--~--~-~--~~~---~--~~
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: a renaming proposal
On Jul 27, 2007, at 6:29 AM, avdd wrote: > > On Jul 27, 9:45 am, jason kirtland <[EMAIL PROTECTED]> wrote: >> This is the last opportunity >> for terminology changes for a while, so I offer this up for >> discussion. > > Does anyone else think "orm.relation" is wrong? Perhaps > "relationship" if you must have a noun, or "relates_to", etc, but > "relation" could cement the popular misunderstanding of "relational > database". > "relation" is wrongish because it conflicts with Codd's term "relation". However, I have pored over SQL and relational articles to see what word they use when they want to describe a table A that joins to table B. and they always say: "relationship". If you look up "relation" and "relationship" in the dictionary, *they mean the same thing*. somehow naming it "relationship" feels weird (though we can go with that if we want). "relates_to", probably more accurate..but the kinds of words we've been using in "properties" (and generally) are nouns. Elixir is the one using the "verb/preposition" style. --~--~-~--~~~---~--~~ 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: a renaming proposal
What popular misunderstanding would that be? I have no problem with any of the terminology from S/A. It all seems unambiguous, and makes sense. Of course, I also studied database theory, relational algebra, and relational calculus at university. ~jon On Jul 27, 5:29 am, avdd <[EMAIL PROTECTED]> wrote: > On Jul 27, 9:45 am, jason kirtland <[EMAIL PROTECTED]> wrote: > > > This is the last opportunity > > for terminology changes for a while, so I offer this up for discussion. > > Does anyone else think "orm.relation" is wrong? Perhaps > "relationship" if you must have a noun, or "relates_to", etc, but > "relation" could cement the popular misunderstanding of "relational > database". > > a. --~--~-~--~~~---~--~~ 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: a renaming proposal
On Jul 27, 9:45 am, jason kirtland <[EMAIL PROTECTED]> wrote: > This is the last opportunity > for terminology changes for a while, so I offer this up for discussion. Does anyone else think "orm.relation" is wrong? Perhaps "relationship" if you must have a noun, or "relates_to", etc, but "relation" could cement the popular misunderstanding of "relational database". a. --~--~-~--~~~---~--~~ 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: a renaming proposal
svilen ha scritto: > Anyway it may depend which audience are u targeting with these names - > those who never seen an API or those for which names are important > only to associate them with a library/version/use-case... both > extremes are equaly uninteresting imo. > I think targeting those who read Fowler's book (or really should) is good enough :-) MetaData is not ambiguous. One of the things I liked at first about SA is that, having just bought the book, it had several of the book's patterns with the same names. --~--~-~--~~~---~--~~ 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: a renaming proposal
On Friday 27 July 2007 11:44:43 Gaetan de Menten wrote: > On 7/27/07, svilen <[EMAIL PROTECTED]> wrote: > > On Friday 27 July 2007 02:45:12 jason kirtland wrote: > > > > - Catalog: > > what is a sqlalchemy's metadata? > > > > >jason> "a catalog of tables available in the database." > > > > to me it holds everything about the "subset of database > > structure", used in the app. > > > > as i have seen, sql-wise the term is metadata. going away from > > sql? To me it is important. sure, it is not The Metadata of the > > server. Why not just Table_collection? And, is it _just_ table > > collection, or there's more to it? Catalog... of what? make it > > TableCatalog then, or just TableSet? elements are uniq and not > > ordered... > > what about DBSchema/Schema/TableSchema - it does match one > > schema, or no? can u have one metadata over tables from 2+ > > schemas? > > As I was reminded on IRC, metadata can hold more than Tables: > > IF you go to the trouble to change that, I'd say simply > "TableCollection" > yah except indexes and sequences can be > in it too > and possibly functions > ok, bad idea then > MetaData is based off of fowler's usage of the word > and domains > and lots of other things > yeah it coujld have functions and domains someday too > it doesnt really right now i guess triggers too? in that case, TableWhatever isn't proper thing. Catalog... some Apple][ memories... Directory? DBSchema? DBStructure? DBDescription? DBMetaData (;-l)? --~--~-~--~~~---~--~~ 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: a renaming proposal
On 7/27/07, svilen <[EMAIL PROTECTED]> wrote: > On Friday 27 July 2007 02:45:12 jason kirtland wrote: > - Catalog: > what is a sqlalchemy's metadata? > >jason> "a catalog of tables available in the database." > to me it holds everything about the "subset of database structure", > used in the app. > > as i have seen, sql-wise the term is metadata. going away from sql? To > me it is important. sure, it is not The Metadata of the server. > Why not just Table_collection? And, is it _just_ table collection, or > there's more to it? Catalog... of what? make it TableCatalog then, or > just TableSet? elements are uniq and not ordered... > what about DBSchema/Schema/TableSchema - it does match one schema, or > no? can u have one metadata over tables from 2+ schemas? As I was reminded on IRC, metadata can hold more than Tables: IF you go to the trouble to change that, I'd say simply "TableCollection" yah except indexes and sequences can be in it too and possibly functions ok, bad idea then MetaData is based off of fowler's usage of the word and domains and lots of other things yeah it coujld have functions and domains someday too it doesnt really right now -- Gaëtan de Menten http://openhex.org --~--~-~--~~~---~--~~ 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: a renaming proposal
On Friday 27 July 2007 02:45:12 jason kirtland wrote: > 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 > Engines would be DataSources, and MetaData would be Catalogs. i'm trying to clarify the meanings of these, lets do semantical analysis of sorts. - Datasource: what is an sqlachemy's engine? >jason> "What database is that bound to?" to me engine mostly meant "the driver that does it". so yes, it's not engine really. But datasource is way to general. Are u going http? although... And it's not readonly - so it's not just "source", source implies "pulling" and never pushing. How about db_driver? data_driver? just driver? or something around it... - Catalog: what is a sqlalchemy's metadata? >jason> "a catalog of tables available in the database." to me it holds everything about the "subset of database structure", used in the app. as i have seen, sql-wise the term is metadata. going away from sql? To me it is important. sure, it is not The Metadata of the server. Why not just Table_collection? And, is it _just_ table collection, or there's more to it? Catalog... of what? make it TableCatalog then, or just TableSet? elements are uniq and not ordered... what about DBSchema/Schema/TableSchema - it does match one schema, or no? can u have one metadata over tables from 2+ schemas? Anyway it may depend which audience are u targeting with these names - those who never seen an API or those for which names are important only to associate them with a library/version/use-case... both extremes are equaly uninteresting imo. i'm not "opposing for the sake of it", i just throw other view-points/ideas.. maybe "catalog" is closer hit than "datasource". And, the names should automaticaly associate to _what_ they really are - datasource talks about data (and not about database) and source (readonly), catalog doesnot talk about tables either. so my picks would be something like DataBaseDriver/DataDriver and TableSet - or TableCatalog. To me these represent better the meanign of them notions, and are not twofold/ambigious. ciao svil --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
