[sqlalchemy] Re: is pool supposed to be able to handle its target db restarting?
On Jan 26, 2007, at 6:05 PM, Jonathan Ellis wrote: On 1/26/07, Michael Bayer [EMAIL PROTECTED] wrote: doing away with the __del__() thing ? what would we gain by removing the __del__() call ? relying on it is buggy. so why have it? youre basically saying, do away with implicit execution. which is the ability to say somestatement.execute(). since if everyone has to try/finally with a close() or whatever, youre pretty much going to want to say conn = engine.connect() / conn.execute(statement) / conn.close()remembering to pull it off of arbitrary execute()'s is not really worth it. this is nothing new, its the exact same paradigm presented to me at the end of the 0.1 series, so i came up with an entirely new way to do everything, i.e. explicit execution via Connection. some people wanted to do it that way, so i gave it to them. at the end of the day, and after all that pain i put on everyone to upgrade when i put out the 0.2 series, 99% of all examples people mail to me (including yours) still use implicit execution totally. i think the __del__() thing works just fine for a huge set of use cases...if youre writing some application where you want to totally control your connections, then you dont use it. we can add an option to disable it (or raise an assertion) for those apps that want to insure they arent relying upon it. i dont think theres too many situations where reliance upon __del__() is going to realistically cause an app to totally hang. if you artificially set a connection pool to exactly one connection and to indefinitely hang on a subsequent request, and then create a command line app that just holds its state statically at that point of hang, then yes youre going to hang. but a web application thats doing requests and then garbage collecting the full state of that request each timei dont see it happening. --~--~-~--~~~---~--~~ 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: Tagging example
i have some notes on how to create instances that are unique to some
identity:
http://www.sqlalchemy.org/trac/wiki/UsageRecipes/UniqueObject
as far as it being a list of normal strings, thats a feature we
havent implemented as of yet. hibernate does it, you can make
collections of ints or strings instead of objects. its not as much a
burning need in python since you can use object tricks to create the
same effect...but i would like to look into that feature someday (tho
it would probably be just my institutionalizing a particular class-
based trick).
On Jan 26, 2007, at 6:37 PM, Damjan wrote:
I've been folowing this document
http://www.thesamet.com/blog/2006/11/17/tutorial-how-to-implement-
tagging-with-turbogears-and-sqlalchemy/
and created this model http://rafb.net/p/M4pfAD74.html (criticism
welcomed).
Now, creating pages and then adding tags to them like so:
p1.tags.append(Tag('test'))
p2.tags.append(Tag('test'))
will actually create two 'test' tags in the database...
also does p1.tags be a list of Tag instances? Can it be a list of
normal strings?
--~--~-~--~~~---~--~~
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: Persistence Layer best practices with SQLAlchemy
On 1/26/07, Michael Bayer [EMAIL PROTECTED] wrote: On Jan 25, 7:28 pm, Allen [EMAIL PROTECTED] wrote: The basic idea of a persistence layer (as I understand it) is that you attempt to isolate applications from the database to the point that the application and the data model can vary independently without requiring major code changes. As the paper above puts it, a well build persistence layer for an application should allow moving tables, renaming tables, renaming columns, and reorganizing tables without affecting the applications that access them. yeahto be honest, one thing that makes SA unique from most other ORMs ive seen is that its specifically *not* trying to accomplish that. as you said, youre not so optimistic about it either. my experience is that those who argue about the object-relational impedance mismatch, for which you can find endless blog/academic articles about, seem to be obsessed with a completely clean separation of objects and database. and that implies that theyd like their application to scurry along doing everything it does without nary a shadow of a relational concept being revealedso...why use a database at all then ? I agree that a complete separation is probably either a) impossible or b) going to lead to code that is so complex and difficult to maintain that it removes any advantage gained. I think there may be a happy medium somewhere in the middle though and I am hopeful that SA can help out there. I think the object and data model need to be fairly close, but I would hope that the software could allow for small variations so both the data model and the object model can be refactored and improved. For example with the ability of SA to map attributes names to columns that are named differently allows some of this. It also appears that being able to map a class to a joined relationship could allow for some very interesting capabilities as well. What I am looking for is guidance about how people use SA to try to reach this middle ground or references to any modules/plugins/extensions that could assist in this regard. I would rather not attempt to recreate the wheel so to speak and I am sure that other people out there have already created better wheels then I could dream to. :) SA's goal is absolutely not to create a programming paradigm or framework which allows pure separation of application/persistence concerns...such a framework could certainly build on top of SA, but within SA we are providing more primitive operations than that. The goal of SA is strictly to provide a rich framework for issuing SQL statements to a database. the ORM part of it, which is totally optional, then takes a straightforward approach to mapping Python classes to database tables and other selectables, and provides maybe the *beginning* of an abstractional layer, but thats about it. it assumes Python is a flexible enough language that its up to the larger framework to figure out where to hide the session.query() calls, if thats whats desired. Agreed. Python does allow a degree of flexibility that makes a pure separation less needed. As a side note, I am trying to see where ActiveMapper would fit into all of this. At first I thought that ActiveMapper would actually tie the classes closer to the data model, but after looking at it further I am starting to think that it still has all the power and flexibility of the other methods of using SA but simple encapsulates the Table and Mapper creation in a single unit. Can anyone tell me if this is a correct assessment? personally I dont really believe in a pure abstractional layer and i think the more time one spends being obsessed with it, the less one ends up getting done. lump it in there with all those other silver bullets. Agreed. The pursuit of silver bullets is a fools errand. I just hope to avoid taking the bullet and is SA and shooting myself in the foot because of lack of understanding. :) Thank you for your comments. -Allen --~--~-~--~~~---~--~~ 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: Persistence Layer best practices with SQLAlchemy
On 1/27/07, Allen Bierbaum [EMAIL PROTECTED] wrote: I agree that a complete separation is probably either a) impossible or b) going to lead to code that is so complex and difficult to maintain that it removes any advantage gained. I modify the schema and code in step during development, once the project is finished and enters into maintanence, the object model stays pretty much fixed. From your initial message, I'm sure whether you wanted to use raw SQL or SA's interface. The latter isolates changes much better than the former, so the rest assumes that's what you're using. Table name changes are pretty simple, change the first argument to Table and all the ForeignKeys that reference it. Field name changes are less obvious. I make use of the key= argument of the Column class because that means my queries don't need to be rewritten. Flexibility beyond that is dependent on how many queries you have scattered around your code. For code that's just using the final mapped objects, you can map pretty much anything you can query onto a particular attribute. I've done a few mapping changes where a field is normalized or de-normalized and the object stays the same. The code using the objects doesn't have to change, but the queries that touch that field generally do. Certain changes are simpler than others, your mileage may vary. I am starting to think that it still has all the power and flexibility of the other methods of using SA but simple encapsulates the Table and Mapper creation in a single unit. Can anyone tell me if this is a correct assessment? ActiveMapper implements the active record pattern while the standard SA ORM interface implements the data mapper pattern (see Fowler's Patterns of Enterprise Architecture for explanations). For basic usage, ActiveMapper is more convenient and is basically a thin wrapper over the standard. The problem is that it's relations are less powerful -- there's no primaryjoin or secondaryjoin, this is an implementation limit and can be fixed -- and quite a few of the features listed in the Advanced Datamapping section of the docs are unavailable to you. You cannot, for example, map multiple tables onto a single object, this is a design limit. You can mix and match ActiveMapper and normal SA mapped objects and definitions, but I prefer to just use active_mapper exclusively. The biggest disadvantage is that the code is spread into three locations. I work around this using code folds in Vim, but it's still a bit clunky. There is another active record mapper called TurboEntity (no ties to TurboGears despite the name), which a number of people on the TG mailing list like. The authors of ActiveMapper and TurboEntity are collaborating on a joint project to replace both with a mapper that implements a DSL which, to me, looks like a mix between Rails' ActiveRecord and Smalltalk. --~--~-~--~~~---~--~~ 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: Persistence Layer best practices with SQLAlchemy
On Jan 27, 2007, at 11:57 AM, Allen Bierbaum wrote: As a side note, I am trying to see where ActiveMapper would fit into all of this. At first I thought that ActiveMapper would actually tie the classes closer to the data model, but after looking at it further I am starting to think that it still has all the power and flexibility of the other methods of using SA but simple encapsulates the Table and Mapper creation in a single unit. Can anyone tell me if this is a correct assessment? there is a project going on involving ActiveMapper and TurboEntity combining to make the next generation of declarative layer. the current ActiveMapper is quite minimal. i think its getting time for them to talk about it a little bit. personally I think ActiveMapper complicates things and also requires that the entire SA api be rewritten, as most ActiveMapper issues refer to SA features that are not available through its interface. --~--~-~--~~~---~--~~ 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: polymorphic mapping with more than 2 level of inheritance
the polymorphic join is fine. the combination of equivalent columns
is not an issue. the creation of the query is built against a
particular mapper's selectable; when a row from that query is passed
to a different mapper due to a polymorphic switch, the row is
translated to be against the columns that the target mapper expects.
the error here is that the Engineer mapper is trying to do a
polymorphic mapper lookup on a row that was given to it by the
polymorphic mapper lookup on Employee, and is trying to use the
column that you gave it, pu_Employee.c.atype, on a row which in fact
links only to the exact Column object table_Employee.c.atype, which
is because the Employee mapper created that row in its translate_row()
step. so rev 2260 adds a flag saying i already did the polymorphic
lookup; youre the mapper for this row.
for homework, you have to tell me if this program will succeed or
fail:
from sqlalchemy import *
meta = MetaData()
t1 = Table('table1', meta,
Column('col1', Integer, primary_key=True),
Column('col2', Integer),
Column('col3', Integer),
Column('col4', Integer),
)
t2 = Table('table2', meta,
Column('col1', Integer, primary_key=True),
Column('col2', Integer),
Column('col3', Integer)
)
j1 = t1.join(t2, t1.c.col1==t2.c.col1)
u1 = union_all(t1.select(), j1.select())
print [t2.corresponding_column(c) for c in u1.c]
On Jan 27, 11:54 am, [EMAIL PROTECTED] wrote:
have u checked this one? it's still failing, same error.
hello.
i'm testing next level of complexity - 3 level inheritance.
C inherits B inherits A, all via table-inheritance, no relations.
A,B are with polymorphic mappers via unions.
e.g. A=Employee, B=Engineer, C=Manager.
The problem is: i cannot query the base polymorphic mapper A.
querying B and C is ok (as well as any other levels above, and/or
non-polymorphic mappers on all levels).
The error is:
sqlalchemy.exceptions.NoSuchColumnError:
Could not locate column in row for column 'pu_Engineer.atype'
(Engineer is level B in this case.)
see/run attached file
--~--~-~--~~~---~--~~
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: KeyError: 'inet'
thanks i added ticket #444 to remind me to put this one in On Jan 24, 7:56 pm, Peter Nixon [EMAIL PROTECTED] wrote: On Wed 24 Jan 2007 00:37, Michael Bayer wrote: no, youre testing it for me first :)Well it seems to work ok :-) Thanks -- Peter Nixonhttp://www.peternixon.net/ PGP Key:http://www.peternixon.net/public.asc application_pgp-signature_part 1KDownload --~--~-~--~~~---~--~~ 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: Tagging example
Well in this case, the Tag class is really unnecesseary --~--~-~--~~~---~--~~ 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: polymorphic mapping with more than 2 level of inheritance
So, ive been working on this crapola pretty much all day... (YOURE WELCOME) ... and the latest is in a branch http://svn.sqlalchemy.org/sqlalchemy/ branches/polymorphic_relations . so, the one thing i really cannot crack at all is how to make polymorphic_union figure out the dupe id column in: table_Employee.join(table_Engineer).select(table_Employee.c.atype == 'Engineer'), since the embedded list of columns comes out only at compilation time for the query. so i think i want to look into modifying Select() to detect this internally and just raise an error. you cant say use_labels on this particular query either because polymorphic_union needs the real column names in order to determine the names for the union. all you have to say is: select([table_Employee, table_Engineer.c.machine], table_Employee.c.atype == 'Engineer', from_obj=[table_Employee.join(table_Engineer)]), and it works, since you manually construct a column list that doesnt contain a dupe. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
