[sqlalchemy] Re: Elixir 0.6.1 released!
Thanks for the info, I guess I didn't realize declarative was added so recently, its been a while since I actually looked at the SA docs (which is where I found it). But you do make some good points about Elixer, I'll have to give it another look, because I do find the way that SA defines relationships to be difficult at times Jose Jorge Vargas wrote: On Mon, Aug 18, 2008 at 11:37 PM, Jose Galvez [EMAIL PROTECTED] wrote: I'm not trying to be an ass, but what are the advantages to using Elixer well you did sound like one :) the first thing is that declarative is very new to SA (0.4.something, and only mainstream in 0.5), while elixir has been around since SA0.2(?) next elixir is more featurefull than declarative, for instance it provides you the ability to build custom relationships [1] there was a really nice example somewhere but I can't find it, maybe it's on the video. the other nice feature is giving you a more OOP-ish api, with elixir you can almost forget you are storing to tables. last but not least, you have some nice magic that will take care of your tables Also I believe there is some subclassing/inheritance goodies That said I'm not the best person to answer this because I'm not a heavy elixir user, I just wanted to point out it has a purpose, and if it seems to overlap with SA is because something new was develop and not the other way around. In fact declarative is an extension distributed with SA, not a core feature and it was added so people (including me) stop complaining about how verbose simple projects where [2], on the other hand elixir is an implementation of Active Record and beyond. [1] http://elixir.ematia.de/apidocs/elixir.relationships.html [2] http://groups.google.com/group/sqlalchemy/browse_thread/thread/817097f376fc808b/2e9ac8e83df54090 Gaetan de Menten wrote: I am very pleased to announce that version 0.6.1 of Elixir (http://elixir.ematia.de) is now available. As always, feedback is very welcome, preferably on Elixir mailing list. This is a minor release featuring some bug fixes (one of them to handle a late rename in SQLAlchemy's 0.5 beta cycle), a new, slighty nicer, syntax for providing custom arguments to the column(s) needed for ManyToOne relationships and some exception messages improvements. The full list of changes can be seen at: http://elixir.ematia.de/trac/browser/elixir/tags/0.6.1/CHANGES What is Elixir? - Elixir is a declarative layer on top of the SQLAlchemy library. It is a fairly thin wrapper, which provides the ability to create simple Python classes that map directly to relational database tables (this pattern is often referred to as the Active Record design pattern), providing many of the benefits of traditional databases without losing the convenience of Python objects. Elixir is intended to replace the ActiveMapper SQLAlchemy extension, and the TurboEntity project but does not intend to replace SQLAlchemy's core features, and instead focuses on providing a simpler syntax for defining model objects when you do not need the full expressiveness of SQLAlchemy's manual mapper definitions. Mailing list http://groups.google.com/group/sqlelixir/about --~--~-~--~~~---~--~~ 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] declarative
What is the proposed stability of declarative functions which I guess are pretty new. From what I've read so far I really like it and was thinking of using it, but was just wondering what the long turn outlook for it looked like? After doing some reading on the new release of Elixir, Elixir looks like a mich simplier and more feature complete then declarative, but It does not look like Elixir works with a legacy databse (but I'm still looking into that) so I was wondering about declarative's long term stability. Thanks Jose --~--~-~--~~~---~--~~ 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: declarative
I take it back about Elixir and legacy databases, it seems to work with them just as easy as sqlalchemy does. I'll have to look much closer at Elixir Jose Jose Galvez wrote: What is the proposed stability of declarative functions which I guess are pretty new. From what I've read so far I really like it and was thinking of using it, but was just wondering what the long turn outlook for it looked like? After doing some reading on the new release of Elixir, Elixir looks like a mich simplier and more feature complete then declarative, but It does not look like Elixir works with a legacy databse (but I'm still looking into that) so I was wondering about declarative's long term stability. Thanks Jose --~--~-~--~~~---~--~~ 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: Elixir 0.6.1 released!
I'm not trying to be an ass, but what are the advantages to using Elixer
over using the declarative syntax such as:
from sqlalchemy import *
from sqlalchemy.orm import relation, scoped_session, sessionmaker
from sqlalchemy.ext.declarative import declarative_base
dbe = create_engine(somedatabaseconnectionstring)
session = scoped_session(sessionmaker(bind=dbe))
mapper = session.mapper
meta = MetaData(bind=dbe)
Base = declarative_base(mapper=mapper)
class People(Base):
__table__ = Table('people', meta, autoload=True)
def __repr__(self):
return 'user: %s %s' % (self.fname, self.lname)
print 'first get everyone in the database'
people = People.query()
for p in people:
print p
Jose
Gaetan de Menten wrote:
I am very pleased to announce that version 0.6.1 of Elixir
(http://elixir.ematia.de) is now available. As always, feedback is
very welcome, preferably on Elixir mailing list.
This is a minor release featuring some bug fixes (one of them to
handle a late rename in SQLAlchemy's 0.5 beta cycle), a new, slighty
nicer, syntax for providing custom arguments to the column(s) needed
for ManyToOne relationships and some exception messages improvements.
The full list of changes can be seen at:
http://elixir.ematia.de/trac/browser/elixir/tags/0.6.1/CHANGES
What is Elixir?
-
Elixir is a declarative layer on top of the SQLAlchemy library. It is
a fairly thin wrapper, which provides the ability to create simple
Python classes that map directly to relational database tables (this
pattern is often referred to as the Active Record design pattern),
providing many of the benefits of traditional databases without losing
the convenience of Python objects.
Elixir is intended to replace the ActiveMapper SQLAlchemy extension,
and the TurboEntity project but does not intend to replace
SQLAlchemy's core features, and instead focuses on providing a simpler
syntax for defining model objects when you do not need the full
expressiveness of SQLAlchemy's manual mapper definitions.
Mailing list
http://groups.google.com/group/sqlelixir/about
--~--~-~--~~~---~--~~
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.4beta6 released !!
Dear Micheal, Does this mean that with web apps since the session is now weak referencing that we will no longer have to call Session.remove() to clear out Sessions? Specifically I'm referencing what Mike Orr wrote in the pylonscookbook. Jose Michael Bayer wrote: This should hopefully be the last of the beta releases before 0.4.0 is released. The big change in this one is that the ORM Session is now *weak referencing* by default, with an option to turn on the old strong referencing behavior. This means that objects in the session get cleared out automatically when they fall out of scope within your application. Objects which have pending changes on them will not get cleared until the session is flushed. Theres also some refinements to how mappers compile, and it should be much less likely that you'd get stuck with an uncompiled mapper. When defining mappers in an inheritance relationship, the superclass mapper needs to be defined before the corresponding subclass mappers (which should be how everyone is doing it anyway...I think). Other than that you can still define mappers in whatever order regardless of relations to each other. Besides those, we have a lot of bug fixes and some more enhancements and speed improvements. We mainly want to see that this one is stable, works in everyone's environment as well or better than all the other betas, and then we should be ready to go. Download 0.4 beta6 at: http://www.sqlalchemy.org/download.html changelog (also at http://www.sqlalchemy.org/CHANGES) : 0.4.0beta6 -- - The Session identity map is now *weak referencing* by default, use weak_identity_map=False to use a regular dict. The weak dict we are using is customized to detect instances which are dirty and maintain a temporary strong reference to those instances until changes are flushed. - Mapper compilation has been reorganized such that most compilation occurs upon mapper construction. This allows us to have fewer calls to mapper.compile() and also to allow class-based properties to force a compilation (i.e. User.addresses == 7 will compile all mappers; this is [ticket:758]). The only caveat here is that an inheriting mapper now looks for its inherited mapper upon construction; so mappers within inheritance relationships need to be constructed in inheritance order (which should be the normal case anyway). - added FETCH to the keywords detected by Postgres to indicate a result-row holding statement (i.e. in addition to SELECT). - Added full list of SQLite reserved keywords so that they get escaped properly. - Tightened up the relationship between the Query's generation of eager load aliases, and Query.instances() which actually grabs the eagerly loaded rows. If the aliases were not specifically generated for that statement by EagerLoader, the EagerLoader will not take effect when the rows are fetched. This prevents columns from being grabbed accidentally as being part of an eager load when they were not meant for such, which can happen with textual SQL as well as some inheritance situations. It's particularly important since the anonymous aliasing of columns uses simple integer counts now to generate labels. - Removed parameters argument from clauseelement.compile(), replaced with column_keys. The parameters sent to execute() only interact with the insert/update statement compilation process in terms of the column names present but not the values for those columns. Produces more consistent execute/executemany behavior, simplifies things a bit internally. - Added 'comparator' keyword argument to PickleType. By default, mutable PickleType does a deep compare of objects using their dumps() representation. But this doesn't work for dictionaries. Pickled objects which provide an adequate __eq__() implementation can be set up with PickleType(comparator=operator.eq) [ticket:560] - Added session.is_modified(obj) method; performs the same history comparison operation as occurs within a flush operation; setting include_collections=False gives the same result as is used when the flush determines whether or not to issue an UPDATE for the instance's row. - Added schema argument to Sequence; use this with Postgres /Oracle when the sequence is located in an alternate schema. Implements part of [ticket:584], should fix [ticket:761]. - Fixed reflection of the empty string for mysql enums. - Changed MySQL dialect to use the older LIMIT offset, limit syntax instead of LIMIT l OFFSET o for folks using 3.23. [ticket:794] - Added 'passive_deletes=all' flag to relation(), disables all nulling-out of foreign key attributes during a flush where the parent object is deleted. - Column defaults and onupdates, executing inline, will
[sqlalchemy] Re: Import problem
what error do you get is you enter import sqlalchemy Jose Goutham Lakshminarayan wrote: This might trivial to most of u but Iam having problems importing sqlalchemy on windows. The installation went without a problem but when i went to site packages directory there was a SQLAlchemy-0.3.10-py2.5.egg folder and no folder called sqlalchemy or a .py file. Moreover i cant import sqlalchemy. It gives module not found error. Can some one help me out? Goutham --~--~-~--~~~---~--~~ 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: SAContext 0.3.0
Well I would prefer not using None and rather making the user pass the correct key, so that way default become no different they using any other key and users could just as simply call their key main or what ever else turns them on. Assuming that they use the correct syntax in the ini file (sqlalchemy.key.uri). So what I would advocate is eliminating the special default and just make users specify the correct key, I think that would be much less ambiguous then None Jose On 7/11/07, Mike Orr [EMAIL PROTECTED] wrote: On 7/11/07, Jose Galvez [EMAIL PROTECTED] wrote: Dear Mike, I've read the doc string in the new sacontext and was just wondering why for add_engine_from_config do you have to explicitly pass None for the default connection? it would make more sense to pass 'default' or better yet nothing all all and assume the default engine. I understand that you are moving away from the the implicit to the explicit which is great, I just thought passing None to mean default is awkward when you could just as easily added None as the default in the method def. (the same could be said about add_engine) It is awkward but Python has no other built-in value for default. Using a string means people may spell it differently, and the .metadata and .engine properties require a fixed value. Making it optional means the second positional argument would sometimes move to the first (like Pylons render_response(/template.html) vs render_response(mako, /template.html), and I'm absolutely opposed to that. Mike doesn't like positional arguments for SAContext but i think they make sense in these cases. So None was the best compromise I could find. I'm open to changing it to default if people like that better. It does mean people would have to pass the exact string or sacontext.DEFAULT (which used to exist but currently doesn't). -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: SAContext 0.3.0
I've just reread the sacontext doc string and realize that what I've said really does not make any sense. To go back a step I would advocate using default rather then None Jose On 7/11/07, Jose Galvez [EMAIL PROTECTED] wrote: Well I would prefer not using None and rather making the user pass the correct key, so that way default become no different they using any other key and users could just as simply call their key main or what ever else turns them on. Assuming that they use the correct syntax in the ini file (sqlalchemy.key.uri). So what I would advocate is eliminating the special default and just make users specify the correct key, I think that would be much less ambiguous then None Jose On 7/11/07, Mike Orr [EMAIL PROTECTED] wrote: On 7/11/07, Jose Galvez [EMAIL PROTECTED] wrote: Dear Mike, I've read the doc string in the new sacontext and was just wondering why for add_engine_from_config do you have to explicitly pass None for the default connection? it would make more sense to pass 'default' or better yet nothing all all and assume the default engine. I understand that you are moving away from the the implicit to the explicit which is great, I just thought passing None to mean default is awkward when you could just as easily added None as the default in the method def. (the same could be said about add_engine) It is awkward but Python has no other built-in value for default. Using a string means people may spell it differently, and the .metadata and .engine properties require a fixed value. Making it optional means the second positional argument would sometimes move to the first (like Pylons render_response(/template.html) vs render_response(mako, /template.html), and I'm absolutely opposed to that. Mike doesn't like positional arguments for SAContext but i think they make sense in these cases. So None was the best compromise I could find. I'm open to changing it to default if people like that better. It does mean people would have to pass the exact string or sacontext.DEFAULT (which used to exist but currently doesn't). -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: query date field
Thanks, everyone for the pointers. Since func is not database agnostic, I think I'll make my own functions in my database module that simply use func so if I ever do switch form mysql to something else at least I'll know where to find all the stuff that needs changing Jose jose wrote: I've got a question that I can't find the answer to. I have a table called seminars with a date field in it to hold the seminar dates. I want to query the table to find all the dates for a specific year. I tried query(Seminars).filter(Seminars.c.date.year==2007) but this gave me an error stating that the col does not have a year property. So how should I do this? Jose --~--~-~--~~~---~--~~ 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
Got it thanks jose Michael Bayer wrote: On Jul 4, 7:30 pm, Jose Galvez [EMAIL PROTECTED] wrote: Thanks Michael, I went back and reread the Proposal thread and I finally get what scalar() does and how it is different form one(). but how would first() differ from scalar() and how would all() differ from list()? At first blush they look like they would return the same type of query object Jose list() and scalar() get deprecated and go away in 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 -~--~~~~--~~--~--~---
