[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: Gedd IF you go to the trouble to change that, I'd say simply TableCollection zzzeek_ yah except indexes and sequences can be in it too stepz and possibly functions Gedd ok, bad idea then zzzeek_ MetaData is based off of fowler's usage of the word stepz and domains stepz and lots of other things zzzeek_ yeah it coujld have functions and domains someday too zzzeek_ 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: lazy table creation
On Jul 27, 7:32 am, King Simon-NFHD78 [EMAIL PROTECTED]
wrote:
You want something like this:
user_table = Table('users', metadata, Column('userid', String(8)))
user_table.create(checkfirst=True)
# or
# metadata.create_all(checkfirst=True)
Documentation is at:
http://www.sqlalchemy.org/docs/metadata.html#metadata_creating
Hope that helps,
Simon
Thanks! I must have blinked when that sentence in the docs went by.
--~--~-~--~~~---~--~~
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: autoload'ing metadata
On Friday 27 July 2007 12:44:49 Christophe de VIENNE wrote:
2007/7/26, [EMAIL PROTECTED] [EMAIL PROTECTED]:
noone wanting to try autoload'ing nor metadatadiff? i am
surprised.. Christophe, u can at least try how much autoload.py
works like your autocode2 - i got lost with 'schema' vs 'dbname'
- and/or add mysql support (;-)
I tried to run it on a mssql db (Although I'd prefer to test it on
a mysql db to see the actual differences from autocode2), but I got
some errors :
well, u have put only mssql in your autocode2 - which i ripped.
i've no idea about mysql - and about mssql either.
up to you if u wanna hack it further, and find out what should be the
way there.
Traceback (most recent call last):
...
'sqlalchemy.databases.mssql.MSSQLDialect_pymssql'): None 'SELECT
tables_77bf.table_name, tables_77bf.table_schema \nFROM
information_schema.tables AS tables_77bf \nWHERE
tables_77bf.table_schema = %(tables_table_schema)s'
{'tables_table_schema':
sqlalchemy.databases.mssql.MSSQLDialect_pymssql object at
0xb78a7f0c}
hmmm
replace the line 91
schema = engine.dialect
with
schema = engine.url.database
this might be equivalent to your old code (if works at all).
i'm not sure what should be there anyway... and have nowhere to test
now.
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
-~--~~~~--~~--~--~---
[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: SQLAlchemy 0.4 MERGED TO TRUNK
On Fri, 27 Jul 2007 04:36:50 - Michael Bayer [EMAIL PROTECTED] wrote: Hey ho - after around 400 revisions the 0.4 branch is merged to trunk: http://svn.sqlalchemy.org/sqlalchemy/trunk Congratulations on the progress for the next generation! That goes for you, Michael Bayer, and the team working so hard on this project. Thank you for sharing all that hard work with everyone. I wonder if you ever imagined that a project started to 'scratch an itch' would ever blossom into something so huge. (in lines of code, documentation.. and time spent!) As only one measure; the quantity of posts on this lists; shows that a lot of people benefit from and depend on your work. While I am not making any money off your blood, sweat, and tears; I still appreciate your work. I just made a donation using the paypal link on the home page. Maybe others can show their appreciation, too. Thanks again. -- michael --~--~-~--~~~---~--~~ 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: SQLAlchemy 0.4 MERGED TO TRUNK
one suggesstion / request.
As your changing everything anyway, can u replace all important {} and
dict() with some util.Dict, and set() with util.Set?
util.Ones can point to dict/set.
The reason is so they can be further globally replaced by user with
OrderedOnes, for example to achieve repeatability - tests etc.
example ones are:
MetaData.tables
unitofwork.UOWTransaction.dependencies
unitofwork.UOWTask.objects
mapperlib.Mapper.save_obj(): table_to_mapper = {}
mapperlib.Mapper._compile_properties(): self.__props = {}
sqlalchemy.topological.QueueDependencySorter.sort(): nodes = {}
these give 90% repeatabliity, but i could not make it 100%. )-:
On Friday 27 July 2007 07:36:50 Michael Bayer wrote:
Hey ho -
after around 400 revisions the 0.4 branch is merged to trunk:
http://svn.sqlalchemy.org/sqlalchemy/trunk
--~--~-~--~~~---~--~~
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: SQLAlchemy 0.4 MERGED TO TRUNK
here the changes i needed to get dbcook (abstraction layer over SA), and its tests going to some extent (70% - relations and expressions are broken): - BoundMetaData - MetaData - lots (15) - metadata.engine.echo=True - lots (14) Whats the difference between create_engine's echo=boolean and MetaData's echo=boolean ?? - import sqlalchemy.orm - i need mostly 4 things off that, but on lots of places (35): create_session, mapper, relation, clear_mappers. several more things like polymorphic_union, class_mapper etc on single occasions (2-3) *** above 3 are very common - but easy - about each SA-using file - query.get_by_whatever - geee, i didnt know i use it (3) - binaryExpression.operator - operator.xx-builtin and not text (1) - type_ vs type - too bad, now i need a key-faking dict. (3+2) why, u're afraid type() will become reserved word or what? - mapper.polymorphic_identity without polymorphic_on - i have these, assuming that having no polymorphic_on ignores anything about polymorphism anyway... now it becomes very tricky as for D(C(B(A))) when making D, it does not really know if was A polymorphic or not... it has to get base_mapper and check its polymorphic_on... (3) - Select (and i guess Clause) lost its accept_visitor - sql.compile traversing takes about more recursion levels than before - not really a problem - InstrumentedList gone = my append(key=value) hack gone.. must find the new way (1) - expression translator - simply forget, it relies on way to many internal hooks, and should be rethinked as of new Query and stuff. The hack4repeateability stopped working :-) which was expected. Same about the 'nicer echo of select' hack. ticket/497 - u forgot me.. So: the bulk of changes, line-count-wise is cosmetical; but anything depending on internal hooks/hacks is ... near-dead. i'm not sure if to go 0.4 or stay 0.3, or try being backward compatible. or add a branch. i did backward compatibility before, but now there are way too many changes now. ciao svil On Friday 27 July 2007 07:36:50 Michael Bayer wrote: Note that this version has some backwards incompatibilities with 0.3 When we get an idea as to how easily people are upgrading to 0.4, we'll figure out how aggressively we want to patch bug fixes from 0.4 back into 0.3 and continue releasing on that series. Currently we plan to keep 0.3 going as long as people need it. --~--~-~--~~~---~--~~ 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: not updated relation one-to-many
OK, first thing is that you should be using backref for this
relationship, it only helps.
But secondly is, you are actually *setting* the relationship here by
manipulating foreign key ids, which is usually not needed; the way to
manipulate relations between ORM instances is by attribute/collection
operations:
a1.t2s.append(a2)
or
a2.t1 = a1
now *if * want to work via the ids and foreign keys, you can; but
you need to refresh those instances (using session.refresh()/
session.expire()) and/or clear your session (session.clear()) before
proceeding. in the first case in your test script, the lazy loader
t2s hadnt been fired off yet which is why the first one works.
On Jul 27, 2007, at 8:07 AM, Michal Nowikowski wrote:
Hello
I've following problem. I've two tables (t1, t2) and relation t1 (one)
- t2 (many):
mapper(T1, t1, properties={t2s: relation(T2, lazy=False)})
mapper(T2, t2, properties={t1: relation(T1, lazy=False)})
When I add row to t1, then to t2, and then run query for first row in
t1, I see one
element in collection t2s - it is ok.
Then when I add second row to t2, the collection in t1 object is not
updated.
It still contains only one element.
Example below.
Could you tell me how to refresh collection in one-to-many relation???
Regards
Michal Nowikowski
from sqlalchemy import *
md = MetaData('sqlite:///a.db', echo=False)
t1 = Table(t1, md,
Column(id, Integer, primary_key=True),
Column(version, Integer))
t2 = Table(t2, md,
Column(id, Integer, primary_key=True),
Column(name, String),
Column(t1_id, Integer, ForeignKey(t1.id)))
md.create_all()
s = create_session()
class T1(object):
pass
class T2(object):
pass
mapper(T1, t1, properties={t2s: relation(T2, lazy=False)})
mapper(T2, t2, properties={t1: relation(T1, lazy=False)})
a1 = T1()
s.save(a1)
s.flush()
a2 = T2()
a2.t1_id = a1.id
a2.name = AAA
s.save(a2)
s.flush()
ra1 = s.query(T1).first()
print [ a.name for a in ra1.t2s ]
a22 = T2()
a22.t1_id = a1.id
a22.name = BBB
s.save(a22)
s.flush()
rra1 = s.query(T1).first()
print [ a.name for a in rra1.t2s ]
--~--~-~--~~~---~--~~
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: autoload'ing metadata
Hi svil,
Still no luck. I don't know if the information_schema module is
supposed to work well with pymssql. Anyway :
Traceback (most recent call last):
File autoload.py, line 233, in ?
autoloader = AutoLoader( engine)
File autoload.py, line 100, in __init__
me.table_names = engine.execute( sqltext)
File /home/cdevienne/prog/sqlalchemy/lib/sqlalchemy/engine/base.py,
line 773, in execute
return connection.execute(statement, *multiparams, **params)
File /home/cdevienne/prog/sqlalchemy/lib/sqlalchemy/engine/base.py,
line 517, in execute
return Connection.executors[c](self, object, *multiparams, **params)
File /home/cdevienne/prog/sqlalchemy/lib/sqlalchemy/engine/base.py,
line 557, in execute_clauseelement
return self.execute_compiled(elem.compile(dialect=self.dialect,
parameters=param), *multiparams, **params)
File /home/cdevienne/prog/sqlalchemy/lib/sqlalchemy/engine/base.py,
line 568, in execute_compiled
self._execute_raw(context)
File /home/cdevienne/prog/sqlalchemy/lib/sqlalchemy/engine/base.py,
line 581, in _execute_raw
self._execute(context)
File /home/cdevienne/prog/sqlalchemy/lib/sqlalchemy/engine/base.py,
line 599, in _execute
raise exceptions.SQLError(context.statement, context.parameters, e)
sqlalchemy.exceptions.SQLError: (DatabaseError) internal error (SQL
Server message 208, severity 16, state 1, line 1:
Invalid object name 'information_schema.tables'.
DB-Lib error message 20018, severity 5:
General SQL Server error: Check messages from the SQL Server.
): SQL Server message 208, severity 16, state 1, line 1:
Invalid object name 'information_schema.tables'.
DB-Lib error message 20018, severity 5:
General SQL Server error: Check messages from the SQL Server.
'SELECT tables_a3c4.table_name, tables_a3c4.table_schema \nFROM
information_schema.tables AS tables_a3c4 \nWHERE
tables_a3c4.table_schema = %(tables_table_schema)s'
{'tables_table_schema': 'sf_tmp'}
--~--~-~--~~~---~--~~
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: not updated relation one-to-many
On 27 Lip, 05:45, King Simon-NFHD78 [EMAIL PROTECTED] wrote: The problem is that when you run your last query, SA sees that there is still an existing T1 object (with the right primary key) in memory (both in the session and in your 'a1' and 'ra1' variables). It deliberately doesn't update them. [cut] You may also be interested in the refresh/expire methods of session: http://www.sqlalchemy.org/docs/unitofwork.html#unitofwork_api_refreshexpire Thanks. expire/refresh is good solution for my problem :) Regards Michal Nowikowski --~--~-~--~~~---~--~~ 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] lazy table creation
I've looked and looked, but can't find any guidance on this. I want a
program that, the first time it's run, creates its tables. I'm
guessing that I need something like this:
try:
user_table = Table('users', metadata, autoload=True)
except NoSuchTableError:
user_table = Table('users', metadata, Column('userid', String(8)))
OTOH, I can't find any examples of anyone doing things this way. Is
there another way that I'm missing? Thanks!
--~--~-~--~~~---~--~~
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
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: Gedd IF you go to the trouble to change that, I'd say simply TableCollection zzzeek_ yah except indexes and sequences can be in it too stepz and possibly functions Gedd ok, bad idea then zzzeek_ MetaData is based off of fowler's usage of the word stepz and domains stepz and lots of other things zzzeek_ yeah it coujld have functions and domains someday too zzzeek_ 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
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: SQLAlchemy 0.4 MERGED TO TRUNK
I'd want to make sure this didn't hurt performance first. (Seems
innocuous enough, but if it's in any sort of inner loop the extra hash
lookup might be noticeable.)
On 7/27/07, svilen [EMAIL PROTECTED] wrote:
one suggesstion / request.
As your changing everything anyway, can u replace all important {} and
dict() with some util.Dict, and set() with util.Set?
util.Ones can point to dict/set.
The reason is so they can be further globally replaced by user with
OrderedOnes, for example to achieve repeatability - tests etc.
example ones are:
MetaData.tables
unitofwork.UOWTransaction.dependencies
unitofwork.UOWTask.objects
mapperlib.Mapper.save_obj(): table_to_mapper = {}
mapperlib.Mapper._compile_properties(): self.__props = {}
sqlalchemy.topological.QueueDependencySorter.sort(): nodes = {}
these give 90% repeatabliity, but i could not make it 100%. )-:
On Friday 27 July 2007 07:36:50 Michael Bayer wrote:
Hey ho -
after around 400 revisions the 0.4 branch is merged to trunk:
http://svn.sqlalchemy.org/sqlalchemy/trunk
--~--~-~--~~~---~--~~
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: lazy table creation
You want something like this:
user_table = Table('users', metadata, Column('userid', String(8)))
user_table.create(checkfirst=True)
# or
# metadata.create_all(checkfirst=True)
Documentation is at:
http://www.sqlalchemy.org/docs/metadata.html#metadata_creating
Hope that helps,
Simon
-Original Message-
From: sqlalchemy@googlegroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of samwyse
Sent: 27 July 2007 13:23
To: sqlalchemy
Subject: [sqlalchemy] lazy table creation
I've looked and looked, but can't find any guidance on this. I want a
program that, the first time it's run, creates its tables. I'm
guessing that I need something like this:
try:
user_table = Table('users', metadata, autoload=True)
except NoSuchTableError:
user_table = Table('users', metadata, Column('userid', String(8)))
OTOH, I can't find any examples of anyone doing things this way. Is
there another way that I'm missing? Thanks!
--~--~-~--~~~---~--~~
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
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
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: SQLAlchemy 0.4 MERGED TO TRUNK
On Friday 27 July 2007 19:48:51 Jonathan Ellis wrote:
I'd want to make sure this didn't hurt performance first. (Seems
innocuous enough, but if it's in any sort of inner loop the extra
hash lookup might be noticeable.)
if lookup is made once in the start of function, should be okay.
which inner loops are so sensitive?
btw there were so many redundantly made dicts and lists before...
my profiling showed (in february or march) that redundant
function-calls kill performance, all else goes negligible.
On 7/27/07, svilen [EMAIL PROTECTED] wrote:
one suggesstion / request.
As your changing everything anyway, can u replace all important
{} and dict() with some util.Dict, and set() with util.Set?
util.Ones can point to dict/set.
The reason is so they can be further globally replaced by user
with OrderedOnes, for example to achieve repeatability - tests
etc.
example ones are:
MetaData.tables
unitofwork.UOWTransaction.dependencies
unitofwork.UOWTask.objects
mapperlib.Mapper.save_obj(): table_to_mapper = {}
mapperlib.Mapper._compile_properties(): self.__props = {}
sqlalchemy.topological.QueueDependencySorter.sort(): nodes = {}
these give 90% repeatabliity, but i could not make it 100%. )-:
--~--~-~--~~~---~--~~
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: autoload'ing metadata
MSSQL is case-sensitive, and wants to see queries to INFORMATION_SCHEMA in
UPPER CASE.
See mssql.py.uppercase_table() for the gory details, or rather, THE GORY
DETAILS ;-)
On 7/27/07, Christophe de VIENNE [EMAIL PROTECTED] wrote:
Hi svil,
Still no luck. I don't know if the information_schema module is
supposed to work well with pymssql. Anyway :
Traceback (most recent call last):
File autoload.py, line 233, in ?
autoloader = AutoLoader( engine)
File autoload.py, line 100, in __init__
me.table_names = engine.execute( sqltext)
File /home/cdevienne/prog/sqlalchemy/lib/sqlalchemy/engine/base.py,
line 773, in execute
return connection.execute(statement, *multiparams, **params)
File /home/cdevienne/prog/sqlalchemy/lib/sqlalchemy/engine/base.py,
line 517, in execute
return Connection.executors[c](self, object, *multiparams, **params)
File /home/cdevienne/prog/sqlalchemy/lib/sqlalchemy/engine/base.py,
line 557, in execute_clauseelement
return self.execute_compiled(elem.compile(dialect=self.dialect,
parameters=param), *multiparams, **params)
File /home/cdevienne/prog/sqlalchemy/lib/sqlalchemy/engine/base.py,
line 568, in execute_compiled
self._execute_raw(context)
File /home/cdevienne/prog/sqlalchemy/lib/sqlalchemy/engine/base.py,
line 581, in _execute_raw
self._execute(context)
File /home/cdevienne/prog/sqlalchemy/lib/sqlalchemy/engine/base.py,
line 599, in _execute
raise exceptions.SQLError(context.statement, context.parameters, e)
sqlalchemy.exceptions.SQLError: (DatabaseError) internal error (SQL
Server message 208, severity 16, state 1, line 1:
Invalid object name 'information_schema.tables'.
DB-Lib error message 20018, severity 5:
General SQL Server error: Check messages from the SQL Server.
): SQL Server message 208, severity 16, state 1, line 1:
Invalid object name 'information_schema.tables'.
DB-Lib error message 20018, severity 5:
General SQL Server error: Check messages from the SQL Server.
'SELECT tables_a3c4.table_name, tables_a3c4.table_schema \nFROM
information_schema.tables AS tables_a3c4 \nWHERE
tables_a3c4.table_schema = %(tables_table_schema)s'
{'tables_table_schema': 'sf_tmp'}
--~--~-~--~~~---~--~~
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: autoload'ing metadata
Hi, Still no luck. I don't know if the information_schema module is supposed to work well with pymssql. Anyway : It works ok on Windows. Have a go at trying an information_schema query directly in PyMSSQL, without using SA at all. That should settle the matter. Paul --~--~-~--~~~---~--~~ 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: Single table inheritance and mapping against a selectable
On Jul 27, 2007, at 4:03 PM, Gaetan de Menten wrote:
so do you just want explicit_columns=True so that no auto-grabbing
of columns occurs ?
I don't know exactly what I want (or maybe it's just I don't care how
it's done). It's just that I found it suboptimal that in some cases
the columns you select are embedded in the from clause while what
you want is modify what is selected before the from clause, whether
this is columns or more complex expressions.
--
yeah look, this is how it works. your table has x, y, and z. you
set up a mapper. x, y and z all become ColumnPropertys on your
mapper, without you doing anything, i.e. no properties dict. if you
set up a properties dict, columns which you map explicitly will
override the normal x, y, z properties...but the rest just get set up
normally.
so waht you want is this:
mapper(X, table, properties={
'x':table.c.x,
'y':table.c.y
}, explicit_columns=True)
which means, set up x and y, but dont go setting up everything else
inside of table.c (i.e., no z).
--~--~-~--~~~---~--~~
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: Single table inheritance and mapping against a selectable
On 7/27/07, Michael Bayer [EMAIL PROTECTED] wrote:
On Jul 27, 2007, at 4:03 PM, Gaetan de Menten wrote:
so do you just want explicit_columns=True so that no auto-grabbing
of columns occurs ?
I don't know exactly what I want (or maybe it's just I don't care how
it's done). It's just that I found it suboptimal that in some cases
the columns you select are embedded in the from clause while what
you want is modify what is selected before the from clause, whether
this is columns or more complex expressions.
--
yeah look, this is how it works. your table has x, y, and z. you
set up a mapper. x, y and z all become ColumnPropertys on your
mapper, without you doing anything, i.e. no properties dict. if you
set up a properties dict, columns which you map explicitly will
override the normal x, y, z properties...but the rest just get set up
normally.
so waht you want is this:
mapper(X, table, properties={
'x':table.c.x,
'y':table.c.y
}, explicit_columns=True)
which means, set up x and y, but dont go setting up everything else
inside of table.c (i.e., no z).
Yeah, that's exactly what I want, except the name explicit_columns
might not be the best. I'd find it natural to be able to put more
complex expressions/properties than simple columns (as in other
mappers), and that name would suggest we can't. I'd rather see the
opposite principle: something along the lines of map_all_columns=False
(though I'm not sold on that particular term).
--
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: Single table inheritance and mapping against a selectable
yeah look, this is how it works. your table has x, y, and z.
you set up a mapper. x, y and z all become ColumnPropertys on
your mapper, without you doing anything, i.e. no properties dict.
if you set up a properties dict, columns which you map
explicitly will override the normal x, y, z properties...but the
rest just get set up normally.
so waht you want is this:
mapper(X, table, properties={
'x':table.c.x,
'y':table.c.y
}, explicit_columns=True)
which means, set up x and y, but dont go setting up everything
else inside of table.c (i.e., no z).
Yeah, that's exactly what I want, except the name explicit_columns
might not be the best. I'd find it natural to be able to put more
complex expressions/properties than simple columns (as in other
mappers), and that name would suggest we can't. I'd rather see the
opposite principle: something along the lines of
map_all_columns=False (though I'm not sold on that particular
term).
what about include_props=[..] and exclude props=[..] ?
i'd rather not list again and again props on inheriting mappers..
--~--~-~--~~~---~--~~
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: Single table inheritance and mapping against a selectable
those are fine with me. if someone could add a ticket and/or implement that would be helpful. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
