[sqlalchemy] Re: autoload'ing metadata
[EMAIL PROTECTED] ha scritto: here some theory on comparing data trees, in order to produce the changeset edit scripts. http://www.pri.univie.ac.at/Publications/2005/Eder_DAWAK2005_A_Tree_Comparison_Approach_to_Detect.pdf The complete title of the paper is A Tree Comparison Approach To Detect Changes in Data Warehouse Structures. data warehouse is the key concept. of course full automation is not possible and not needed - but why not do maximum effect/help with minimum resources? I've not read it, but what is working for data warehouse could fail miserably in a normalized database. --~--~-~--~~~---~--~~ 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 Thursday 26 July 2007 11:37:08 Marco Mariani wrote: [EMAIL PROTECTED] ha scritto: here some theory on comparing data trees, in order to produce the changeset edit scripts. http://www.pri.univie.ac.at/Publications/2005/Eder_DAWAK2005_A_Tr ee_Comparison_Approach_to_Detect.pdf The complete title of the paper is A Tree Comparison Approach To Detect Changes in Data Warehouse Structures. data warehouse is the key concept. of course full automation is not possible and not needed - but why not do maximum effect/help with minimum resources? I've not read it, but what is working for data warehouse could fail miserably in a normalized database. sure. there are graphs and not just trees. Apart of that, same thing, nodes and edges. u can try the metadatadiff.py, there's lots of node-types to add/describe but IMO the idea is there. or u can keep doing it by hand. choice is yours. Actualy, i'm the worst one to develop this - i have no enough experience with sql and db-admining in general, nor i know _all_ internals of SA. But hey... --~--~-~--~~~---~--~~ 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: MSSQL Time
you may do better to focus your efforts on getting PyODBC working better on Unix. Agreed here. One stable and supportable DBAPI for MSSQL would be really nice. --~--~-~--~~~---~--~~ 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] a renaming proposal
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: Dialect default schema
I'm going to reply here, as I can't seem to login to trac again. I did manage to get comments in for #685 #679 - committed in r3050 #684 - committed in r3051 #685 - needs more discussion see the Trac comments Thanks for the patches! Rick On 7/26/07, Christophe de VIENNE [EMAIL PROTECTED] wrote: 2007/7/26, Christophe de VIENNE [EMAIL PROTECTED]: Last thing : could someone tell me if the patches I posted for mssql looks 'commitable', because I'd prefer fixing those if needed before continuing my failing unit-tests slow (one per day) review. Forgot the ticket numbers, sorry : http://www.sqlalchemy.org/trac/ticket/679 http://www.sqlalchemy.org/trac/ticket/684 http://www.sqlalchemy.org/trac/ticket/685 --~--~-~--~~~---~--~~ 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: MSSQL Time
Hi, -- Pyodbc has troubles with the SQL 2000 syntax of select scope_identity() This one is fixed, at least if you use a modified PyODBC :-) 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: Dialect default schema
2007/7/26, Christophe de VIENNE [EMAIL PROTECTED]: Last thing : could someone tell me if the patches I posted for mssql looks 'commitable', because I'd prefer fixing those if needed before continuing my failing unit-tests slow (one per day) review. Forgot the ticket numbers, sorry : http://www.sqlalchemy.org/trac/ticket/679 http://www.sqlalchemy.org/trac/ticket/684 http://www.sqlalchemy.org/trac/ticket/685 --~--~-~--~~~---~--~~ 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: MSSQL Time
what needs to be modified? can it be done by a src-patch? maybe i can apply it runtime (;-) I think the patch has been out for a few weeks now, so it will likely be in the next release of pyodbc. There is also an easy workaround, pass use_scope_identity = False to the Engine ctor, and it will use @@IDENTITY instead of SCOPE_IDENTITY(). Rick --~--~-~--~~~---~--~~ 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: Dialect default schema
Hi Rick, Thanks for the explanations. My confusion between database and schema comes from how there words are inter-changeable in mysql. I'll rethink all of that later, and make sure I understand it correctly before proposing a patch. --~--~-~--~~~---~--~~ 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: Dialect default schema
Thanks for having a look at the tests, Christophe. Responses below: The reason is that MSSQLDialect.get_default_schema_name takes no argument, while the unittext gives it an engine. The Mssql dialect, for example, does take an argument. It looks to me like get_default_schema_name() has recently been refactored a bit: it previously took no parameters. For some reason, the MSSQL module (and from the looks of things, the mysql module as well) were not updated. Not sure I follow your second sentence here. Having a closer look at MSSQLDialect.get_default_schema_name , it simply returns self.schema_name, which is initialised in __init__ with the value dbo. This is were I don't know what to think. Isn't the default schema depending on the connection ? If so why is it initialized to dbo ? No, the *current* schema is dependent on connection. The default schema is what you get if you don't specify anything else. For MSSQL the default schema is dbo (short for DabaseBaseOwner). More on that below. Another strange thing : MSSQLDialect defines a set_default_schema_name, and it's the only dialect to do that. That was by user request, see the archives. Before patching this in the wrong way, I'd like to have a little bit more details on how the default_shema stuffs are supposed to work. Sub-question : shouldn't the set_default_schema_name issue a USE name ? No, you're confusing schemas and databases. Use name sets a current database name, not a current schema. Search the archives again for previous discussion of schemas on MSSQL. There's been confusion in the past between the terms owner and schema. MSSQL and (some) other databases support a three-level namespace: select * from database.schema.table Confusingly, in earlier documentation (pre MSSQL-2005) for MSSQL, Microsoft would refer to the middle name as an owner: select * from database.owner.table That middle name, whatever you want to call it, has a system default if not explicitly specified. That's what get_default_schema_name() is supposed to return, or at least that's my understanding of it. Last thing : could someone tell me if the patches I posted for mssql looks 'commitable', because I'd prefer fixing those if needed before continuing my failing unit-tests slow (one per day) review. I'll have a look and reply in the tickets themselves. --~--~-~--~~~---~--~~ 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: MSSQL Time
The dependancy chains looks like this (more or less): pymssql == DBlib == FreeTDS == wire pyodbc (Unix) == iodbc / unixodbc == FreeTDS == wire pyodbc (Win) == ms-odbc == OLEdb == wire The unicode problem for pymssql is in DBlib, not FreeTDS Rick On 7/26/07, Christophe de VIENNE [EMAIL PROTECTED] wrote: 2007/7/26, Paul Johnston [EMAIL PROTECTED]: One thing PyMSSQL will never support is Unicode - the MSSQL interface is uses is deprecated and just doesn't do unicode. For that reason, you may do better to focus your efforts on getting PyODBC working better on Unix. Right at the minute though it's more problematic than PyMSSQL. I could see that... One thing though : - pymssql, on unix, is based on freetds - pyODBC, at least on my system, use an ODBC driver based on freetds The question is : if pymssql does not support unicode, does it mean that freetds doesn't ? Sub-Question : if FreeTDS supports unicode, is it realistic to try and modify pymssql to make it more specific to freetds and support unicode ? Christophe --~--~-~--~~~---~--~~ 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
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 (;-) http://dbcook.svn.sourceforge.net/viewvc/*checkout*/dbcook/trunk/autoload.py http://dbcook.svn.sourceforge.net/viewvc/*checkout*/dbcook/trunk/metadatadiff.py requires dbcook only for the test have fun --~--~-~--~~~---~--~~ 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: MSSQL Time
2007/7/26, Paul Johnston [EMAIL PROTECTED]: One thing PyMSSQL will never support is Unicode - the MSSQL interface is uses is deprecated and just doesn't do unicode. For that reason, you may do better to focus your efforts on getting PyODBC working better on Unix. Right at the minute though it's more problematic than PyMSSQL. I could see that... One thing though : - pymssql, on unix, is based on freetds - pyODBC, at least on my system, use an ODBC driver based on freetds The question is : if pymssql does not support unicode, does it mean that freetds doesn't ? Sub-Question : if FreeTDS supports unicode, is it realistic to try and modify pymssql to make it more specific to freetds and support unicode ? Christophe --~--~-~--~~~---~--~~ 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: MSSQL Time
Hi, I see. Are the reasons for thoses failures well known ? fixable ? If it's not too tricky I could spend a bit of time on it in a little while. I expect most of the problems are fixable, with relative degrees of easiness. I've been trying to get all the tests working on Windows for a while now (on and off) and am left with a handful of tricky ones. One thing PyMSSQL will never support is Unicode - the MSSQL interface is uses is deprecated and just doesn't do unicode. For that reason, you may do better to focus your efforts on getting PyODBC working better on Unix. Right at the minute though it's more problematic than PyMSSQL. 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] Dialect default schema
Hi, I'm looking why the unittest SchemaTest.test_create_with_defaultschema does not pass with MS-SQL. The reason is that MSSQLDialect.get_default_schema_name takes no argument, while the unittext gives it an engine. The Mssql dialect, for example, does take an argument. Having a closer look at MSSQLDialect.get_default_schema_name, it simply returns self.schema_name, which is initialised in __init__ with the value dbo. This is were I don't know what to think. Isn't the default schema depending on the connection ? If so why is it initialized to dbo ? Another strange thing : MSSQLDialect defines a set_default_schema_name, and it's the only dialect to do that. Before patching this in the wrong way, I'd like to have a little bit more details on how the default_shema stuffs are supposed to work. Sub-question : shouldn't the set_default_schema_name issue a USE name ? Last thing : could someone tell me if the patches I posted for mssql looks 'commitable', because I'd prefer fixing those if needed before continuing my failing unit-tests slow (one per day) review. Thanks, Christophe --~--~-~--~~~---~--~~ 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: Dialect default schema
Thanks for the commits I didn't say my last word for #685... I'll be back ! Christophe 2007/7/26, Rick Morrison [EMAIL PROTECTED]: I'm going to reply here, as I can't seem to login to trac again. I did manage to get comments in for #685 #679 - committed in r3050 #684 - committed in r3051 #685 - needs more discussion see the Trac comments Thanks for the patches! Rick On 7/26/07, Christophe de VIENNE [EMAIL PROTECTED] wrote: 2007/7/26, Christophe de VIENNE [EMAIL PROTECTED] : Last thing : could someone tell me if the patches I posted for mssql looks 'commitable', because I'd prefer fixing those if needed before continuing my failing unit-tests slow (one per day) review. Forgot the ticket numbers, sorry : http://www.sqlalchemy.org/trac/ticket/679 http://www.sqlalchemy.org/trac/ticket/684 http://www.sqlalchemy.org/trac/ticket/685 --~--~-~--~~~---~--~~ 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] SQLAlchemy 0.4 MERGED TO TRUNK
Hey ho - after around 400 revisions the 0.4 branch is merged to trunk: http://svn.sqlalchemy.org/sqlalchemy/trunk Note that this version has some backwards incompatibilities with 0.3, which have been described on this mailing list in a previous thread. We also might be going with the name changes of MetaData/Engine to Catalog/Datasource (feel free to chime in on that, anyone...?), however the old names will remain available throughout 0.4 regardless of what we do with that. A document in progress describing 0.4 is at: http://www.sqlalchemy.org/trac/wiki/WhatsNewIn04 Suffice to say that this new series is utterly huge. I'm hoping it provides a completely new level of experience in comparison to anything previous. We now have seven active committers, well over 800 unit tests and we're into the 3000s revision-wise...so the shape of SQLAlchemy development is a completely different beast than it was just a year ago. My immediate focus is on documentation, which will start with just getting all the new capabilities into the current document structure; later, we might want to restructure/reformat the docs for clarity. So far just the chapter on sessions has a description of the new transactional capabilities (and simplified interface) for Session; a link to the docs-in-progress is on the download page of the site. The remaining tickets on the 0.4 milestone, if not closed before release, will move into the 0.4xx milestone. Those working from 0.3 SVN should switch over to the maintenance branch at: http://svn.sqlalchemy.org/sqlalchemy/branches/rel_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: MSSQL Time
Hi, one suggestion - why not make one organisational ticket and list all these there? compiled from other mails too? and any other issues about mssql? and keep it up-to-date? Actually, I think many of these issues are significant enough to have individual tickets. We're not 100% up-to-date, but just do a Trac query to see the MSSQL tickets: http://www.sqlalchemy.org/trac/query?status=newstatus=assignedstatus=reopenedcomponent=mssqlorder=priority 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 -~--~~~~--~~--~--~---
