[sqlalchemy] Re: whats going to break in 0.4
On Jul 3, 10:00 pm, David Bolen <[EMAIL PROTECTED]> wrote: > In re-reading the documentation with your comments in mind, it's clear > that the docs do mention connecting a normal MetaData object, but the > examples (and those in the source tree) tend to use BoundMetaData or > DynamicMetaData, so I think I probably mentally excluded a plain > MetaData as an option. The fact that the discussion of the single > global Metadata object also uses DynamicMetaData probably didn't help > my mental picture. Of course, my bad for not also checking out the > class itself. Perhaps having the docs show the use of connect() with > MetaData itself might be helpful to other new users. this is all stuff thats been sorting itself out as we've gone through 0.3 versions. At this stage I can see that having the name "BoundMetaData" floating around there works against things being simple, so the docs/book are going to talk mostly about "MetaData". for DMD it seems like it would probably be a good idea to call it ThreadLocalMetaData. ThreadLocalMetaData is very specific to that one less common use case where a single process dishes out among many independent databases. the pattern im starting to use in 0.4 with metadata replaces 'connect()' with just the 'engine' property: meta = MetaData() engine = create_engine(...) meta.engine = engine as well as: meta = MetaData() meta.engine = 'sqlite://' --~--~-~--~~~---~--~~ 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: whats going to break in 0.4
jason kirtland <[EMAIL PROTECTED]> writes: > DynamicMetaData is not deprecated, but it may be renamed in 0.4 to > clarify its role. For this setup, a MetaData will suffice- it is > "dynamic" as in late binding and re-bindable. After you get your > engine sorted out, you can connect() the engine and metadata just > as you do now. The binding will take effect process-wide. Ah, that's definitely a misunderstanding on my part (and is perhaps the sort of thing Michael was referring to). I don't need thread-specific connections, but did mentally linked the ability to use connect() at all with DynamicMetaData. In re-reading the documentation with your comments in mind, it's clear that the docs do mention connecting a normal MetaData object, but the examples (and those in the source tree) tend to use BoundMetaData or DynamicMetaData, so I think I probably mentally excluded a plain MetaData as an option. The fact that the discussion of the single global Metadata object also uses DynamicMetaData probably didn't help my mental picture. Of course, my bad for not also checking out the class itself. Perhaps having the docs show the use of connect() with MetaData itself might be helpful to other new users. -- David --~--~-~--~~~---~--~~ 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: whats going to break in 0.4
David wrote: > Just wondering - I've noticed you make similar DynamicMetaData > comments in other responses in the past. Downplayed or not, do > you consider it deprecated in an way? For me it seems the only > natural way to set up my meta data. > > For example, my server has a schema.py module establishing the > table structure, but which at module import time has no idea > where the database engine is going to be. So the metadata in the > schema.py module is a DynamicMetaData instance. > > Elsewhere, startup code determines the database location, > creating the engine referencing it, and then connects the meta > data instance in the already loaded schema module to that engine. DynamicMetaData is not deprecated, but it may be renamed in 0.4 to clarify its role. For this setup, a MetaData will suffice- it is "dynamic" as in late binding and re-bindable. After you get your engine sorted out, you can connect() the engine and metadata just as you do now. The binding will take effect process-wide. DynamicMetaData works just the same, but the binding is late AND scoped per-thread. It's fairly rare to need that, except... Barry wrote: > I have exactly the same architecture and exactly the same > question. In fact, my goal in Mailman 3 is to be able to let > sites configure the system to use any supported database backend, > just by tweaking the configuration variable that specifies the > engine url. We'll ship with SQLite, but it would be awesome if I > didn't have to do anything else to 'automatically' support > PostgreSQL or MySQL, etc. Although I haven't tried it with these > other backends, it currently works great with alternative SQLite > database file locations (such as the tempfile one I use during a > test suite run). The regular MetaData gives you this configuration flexibility for a given installation. If you want to support simultaneous and distinct 'configurations' within a threaded process, each with its own set of database tables (possibly mixing backends as well), then a DMD is perfect. Every thread connects the DMD to the engine of its choice before work starts. In a Mailman context I could imagine a single fat worker process at an ISP that serviced lots of domains, each "owned" by a different user with separate data storage. -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: whats going to break in 0.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 3, 2007, at 6:46 PM, David Bolen wrote: > Michael Bayer <[EMAIL PROTECTED]> writes: > >> 4. global_connect() / default_metadata > (...) >>(...) Plus it used DynamicMetaData which >> is a totally misunderstood object that isnt going away but will be >> much more downplayed. youre responsible for your own MetaData object >> and telling your Table objects about it. > > Just wondering - I've noticed you make similar DynamicMetaData > comments in other responses in the past. Downplayed or not, do you > consider it deprecated in an way? For me it seems the only natural > way to set up my meta data. > > For example, my server has a schema.py module establishing the table > structure, but which at module import time has no idea where the > database engine is going to be. So the metadata in the schema.py > module is a DynamicMetaData instance. > > Elsewhere, startup code determines the database location, creating the > engine referencing it, and then connects the meta data instance in the > already loaded schema module to that engine. > > Any other approach would seem to imply knowing the engine URL at the > point when my schema module is being imported (so it can be used to > create the meta data). > > Is this what you're considering being "totally misunderstood"? I have exactly the same architecture and exactly the same question. In fact, my goal in Mailman 3 is to be able to let sites configure the system to use any supported database backend, just by tweaking the configuration variable that specifies the engine url. We'll ship with SQLite, but it would be awesome if I didn't have to do anything else to 'automatically' support PostgreSQL or MySQL, etc. Although I haven't tried it with these other backends, it currently works great with alternative SQLite database file locations (such as the tempfile one I use during a test suite run). Note that I'm using Elixir, but I don't think that should matter. I really hope the feature is retained. I'd actually be surprised if it went away because it seems like such a huge win for SA. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRorVQHEjvBPtnXfVAQJCQgP9EKxAKqfEq3upZP3JzI+SaE78sDy3db3c AKF2mmqa+2C6PIaY7sXCpD3e2ewRwrVKxZU+KpPjoAk+yoscn7gkIIwqVfrsvasK 5seYu0pHLeoHJtIyc36Us2o3NS941oeP4WalBhHqJ/rG0Vn1Lmy/Qzry/wEbHGo6 9ZORjvwGMtE= =TaWK -END PGP SIGNATURE- --~--~-~--~~~---~--~~ 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: whats going to break in 0.4
Michael Bayer <[EMAIL PROTECTED]> writes: > 4. global_connect() / default_metadata (...) >(...) Plus it used DynamicMetaData which > is a totally misunderstood object that isnt going away but will be > much more downplayed. youre responsible for your own MetaData object > and telling your Table objects about it. Just wondering - I've noticed you make similar DynamicMetaData comments in other responses in the past. Downplayed or not, do you consider it deprecated in an way? For me it seems the only natural way to set up my meta data. For example, my server has a schema.py module establishing the table structure, but which at module import time has no idea where the database engine is going to be. So the metadata in the schema.py module is a DynamicMetaData instance. Elsewhere, startup code determines the database location, creating the engine referencing it, and then connects the meta data instance in the already loaded schema module to that engine. Any other approach would seem to imply knowing the engine URL at the point when my schema module is being imported (so it can be used to create the meta data). Is this what you're considering being "totally misunderstood"? -- David --~--~-~--~~~---~--~~ 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: Creating where clauses programatically
On Jul 3, 4:06 pm, mc <[EMAIL PROTECTED]> wrote: > I managed to avoid this issues because for select and insert I can use > dictionaries as arguments of execute(). > For update, I must create a where clause from a list of conditions I > have as a dictionary. > How do I do this programatically? and_(*[table.c[key]==mydict[key] for key in mydict]) --~--~-~--~~~---~--~~ 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: last_inserted_ids()
On Jul 3, 4:01 pm, mc <[EMAIL PROTECTED]> wrote: > What is the correct documentation for it? > The docs say it returns the primary key but for now I see it returns > an auto increment field (which is not part of the key). I doubt thats true. but also, this function has been reworked to be a lot stronger in 0.3.9; try the 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: whats going to break in 0.4
On Jul 3, 2:36 pm, Paul Johnston <[EMAIL PROTECTED]> wrote: > Hi Mike, > > Your proposal sounds pretty sensible, in fact I don't use most of those > features. Just one concern: > > >2. assignmapper query methods > > Are the basics like select and select_by still going to be available > directly? I hope so, as I use them extensively. select and select_by are exactly the methods that wont be directly off the class; they will be available as class.query.select_by(whatever). however, select() and select_by() are deprecated throughout 0.4, in favor of filter()/filter_by() and other generative methods...theyll be gone by 0.5. --~--~-~--~~~---~--~~ 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] Creating where clauses programatically
I managed to avoid this issues because for select and insert I can use dictionaries as arguments of execute(). For update, I must create a where clause from a list of conditions I have as a dictionary. How do I do this programatically? --~--~-~--~~~---~--~~ 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: last_inserted_ids()
I believe that the documentation is quite clear last time i saw it. Last time i used it, if there is an incremented key, then it would return that. But it does not return simply any primary key. Someone correct me if i am wrong. Regards, Alaa Salman On 7/3/07, mc <[EMAIL PROTECTED]> wrote: > > > What is the correct documentation for it? > The docs say it returns the primary key but for now I see it returns > an auto increment field (which is not part of the key). > > > > > --~--~-~--~~~---~--~~ 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] last_inserted_ids()
What is the correct documentation for it? The docs say it returns the primary key but for now I see it returns an auto increment field (which is not part of the key). --~--~-~--~~~---~--~~ 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: How to lock using sqlalchemy
Thank you very much, Michael. It was very clear and helpful and help set my mind straight on the issue. One of the things that confused me was the term "optimistic locking" (used elsewhere, not by yourself). In the optimistic approach, there is no locking at all. On Jul 1, 11:28 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: > On Jul 1, 2007, at 11:36 AM, mc wrote: > > > > > Thanks. > > > You say you are not a fan. What is the preferred way to solve the > > problem I described? > > optimistically. i would ensure that appropriate constraints are > placed upon the table such that two conflicting INSERT statements > would result in one of them raising an exception; when the second > client encounters this exception, it starts over again and re-SELECTs > the row from the table. The case for the optimistic approach is one > of "how often will a confict reasonably take place ?" I think > conficts on INSERT, for all the use cases I can think of (such as > inserting unique keywords), are exceedingly rare, since they > correspond usually to end-user activities, where two users come up > with the same new information at the exact same time. Even if you > did have thousands of users hammering an application where many are > expected to come up with the exact same information (such as, > everyone is going to tag their photos with "kids" and "pets" which > get added to a table of unique keywords), once a fair degree of all > that "unique" data is inserted, then you'd no longer have conflicts, > and the pessimistic locking would then add tremendous and almost > always unnecessary latency to an applciation that has thousands of > users hammering it. If I were running a really big website, id even > try pre-populate the table with expected values before going live. > > on the other hand, if end users are not the issue, and you are > instead writing an application that expects to have INSERT conflicts > because it spawns a huge number of worker threads that are all > operating upon the same data, locking the whole table for each INSERT > will completely defeat the purpose of having worker threads, and you > might as well not use them. --~--~-~--~~~---~--~~ 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: whats going to break in 0.4
Hi Mike, Your proposal sounds pretty sensible, in fact I don't use most of those features. Just one concern: >2. assignmapper query methods > > Are the basics like select and select_by still going to be available directly? I hope so, as I use them extensively. 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: MSSQL Insert problem
Hi, Oh, you're running on Linux. pymssql is probably your best bet, but you can still expect lots of things to break. SA/MSSQL is now pretty solid on Windows, perhaps that's an option for you. Paul fw wrote: >Thanks Paul for your answer > >but > >I was using pymssql. > > >Now, I am trying to use pyodbc and see if your fix would help... after >struggling to get the URI right on my Linux box, it now simply >crashes ... No error message no nothing, it just dies. > >I'll keep looking > >Cheers >François, > > --~--~-~--~~~---~--~~ 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: major help required with SQLAlchemy and Turbogears.
> Great. This gives us a very good reason to shift everything we have > to Pylons. I like the fact that Pylons gives us that controller as I > think that control is very important in developing a robust > application. I want to know what goes one versus having the framework > do everything for me. Moving to pylons now. You can also turn off automatic transaction handling in TurboGears. It's a one line config change, and then you are back in controll of your transactions. But the on/off switch is a bit too course grained for what we ultimately want, so TG 2 will have a much more configurable transaction system. --Mark --~--~-~--~~~---~--~~ 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: Field with constant
select([literal("1").label(field)], from_obj=[foo])
or to not use the bind param
select([literal_column("1").label(field)], from_obj=[foo])
On Jul 3, 9:32 am, Expo <[EMAIL PROTECTED]> wrote:
> If I would make a select with a field set to a constant like this:
>
> SELECT 1 AS field FROM foo
>
> how is the select()'s field definition ? I'v tried with:
>
> select([1], from_obj=[foo])
>
> but field has no name.
--~--~-~--~~~---~--~~
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: Field with constant
Expo ha scritto: > If I would make a select with a field set to a constant like this: > > SELECT 1 AS field FROM foo > > how is the select()'s field definition ? I'v tried with: > > select([1], from_obj=[foo]) > > but field has no name. > > select(["1 as bar"], from_obj=[foo]) Glauco -- ++ Glauco Uri - Programmatore glauco(at)allevatori.com Sfera Carta Software(r) [EMAIL PROTECTED] Via Bazzanese,69 Casalecchio di Reno(BO) - Tel. 051591054 ++ --~--~-~--~~~---~--~~ 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 problem with my MySql server
its this code
decode_from = connection.execute("show variables like
'character_set_results'").fetchone()[1]
this bug is because you have a very old version of MySQL..if you can
figure out what the above code needs for your mysql we can patch 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: Mapper based on a select generates wrong and unnecessary INSERTs
On Jul 3, 5:26 am, klaus <[EMAIL PROTECTED]> wrote: > Yes, of course. ;-) But is it possible not to map certain columns? > Preferably, without using a select and listing every single column > that should be present? well not including those columns in the selectable is the easiest way to do this. it would be a mess to offer both "inclusive" and "exclusive" APIs for indicating which columns you want. mapping to a select among three tables is a pretty uncommon use case. > > Foreign key columns are obvious candidates to be left out, because the > relations should be used instead. Currently, I always rename them into > private attributes (with a leading underscore). the join() object has the ability to "flatten" its columns list like this, using the method myjoin.select(fold_equivalents=true). but also, you can "flatten" the columns at the attribute level, described in the docs on the site. > > BTW, the mapper might want to check that keys are nonempty strings and > no two columns are mapped to the same attribute (currently, the last > one wins). multiple columns mapped to a single attribute is a common case, as above where two attributes share the same value via foreign key relationship. this case is featured in the main documentation on mapping to selects. primary keys columns starting out as empty is usually the rule and not the exception when an INSERT is performed since column defaults or sequences usually provide the new primary key values. > > Best regards > Klaus > > On 2 Jul., 18:12, Michael Bayer <[EMAIL PROTECTED]> wrote: > > > On Jul 2, 2007, at 10:40 AM, klaus wrote: > > > > I would rather ask: How can this behavior be avoided? Is it possible > > > to mark some columns as read-only/no-write-back? > > > just remove the primary key columns of the "non-write" tables from > > the columns clause of the select. --~--~-~--~~~---~--~~ 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] Field with constant
If I would make a select with a field set to a constant like this: SELECT 1 AS field FROM foo how is the select()'s field definition ? I'v tried with: select([1], from_obj=[foo]) but field has no name. --~--~-~--~~~---~--~~ 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: Mapper based on a select generates wrong and unnecessary INSERTs
Yes, of course. ;-) But is it possible not to map certain columns? Preferably, without using a select and listing every single column that should be present? Foreign key columns are obvious candidates to be left out, because the relations should be used instead. Currently, I always rename them into private attributes (with a leading underscore). BTW, the mapper might want to check that keys are nonempty strings and no two columns are mapped to the same attribute (currently, the last one wins). Best regards Klaus On 2 Jul., 18:12, Michael Bayer <[EMAIL PROTECTED]> wrote: > On Jul 2, 2007, at 10:40 AM, klaus wrote: > > > > > I would rather ask: How can this behavior be avoided? Is it possible > > to mark some columns as read-only/no-write-back? > > just remove the primary key columns of the "non-write" tables from > the columns clause of the select. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
