Re: [sqlalchemy] SQLAlchemy 0.6.6 Released
[Michael Bayer, 2011-01-09] > The 0.6 series is not surprisingly our most successful series ever, > with SQLA 0.6.5 racking up 36,000 downloads from Pypi in a period of > 76 days, approximately 15K per month, plus about 2K a month from > Sourceforge. + at least 4241 installations via .deb files (note that only a tiny fraction of Debian machines send the popcon¹ data so the number is probably a lot higher) [¹] http://qa.debian.org/popcon.php?package=sqlalchemy -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] SQLAlchemy 0.6.6 Released
On 09/01/2011 16:25, Michael Bayer wrote: The limitations of distutils are also troubling here. In my own work app, we use pip in conjunction with a Makefile and for the SQLAlchemy install the flag is on in the Makefile. In that regard the flag being off by default doesn't feel like that big a deal to me personally. Anyone know how to set this flag in a buildout setup? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] SQLAlchemy 0.6.6 Released
I remain a little nervous about the C extensions, not as much because the current code is unreliable, but because I'd like there to be a whole lot more C code here. I've used the existing C extensions quite a bit and done tons of profiling - they really don't account for the vast majority of time spent in large ORM operations, and they don't do much for a non-ORM app that emits a lot of statements. They just cut down on an app that is non-ORM and needs to fetch very large result sets. Basically I'd need a resource that can do lots more C code for me, if not myself since it just would take a huge block of extra time for me to get into it, before I'd feel good about the C code overall and confident that I can put out releases in a timely manner which would now require 100% reliable C code. The limitations of distutils are also troubling here. In my own work app, we use pip in conjunction with a Makefile and for the SQLAlchemy install the flag is on in the Makefile. In that regard the flag being off by default doesn't feel like that big a deal to me personally. On Jan 9, 2011, at 3:33 AM, Wichert Akkerman wrote: > Hi Mike, > > On 1/9/11 00:14 , Michael Bayer wrote: >> The majority of my time is now spent developing 0.7, which is nearly ready >> for beta releases pending a few more little features I'd like to try to get >> in. 0.7 is really exciting with its new event API, lots of other nice >> touches and of course the most radical reduction in callcounts we've had in >> a few years. > > Has been there a decision on enabling the C extensions by default in 0.7, or > is that still too controversial? > > Regards, > Wichert. > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To post to this group, send email to sqlalch...@googlegroups.com. > To unsubscribe from this group, send email to > sqlalchemy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] SQLAlchemy 0.6.6 Released
Hi Mike, On 1/9/11 00:14 , Michael Bayer wrote: The majority of my time is now spent developing 0.7, which is nearly ready for beta releases pending a few more little features I'd like to try to get in. 0.7 is really exciting with its new event API, lots of other nice touches and of course the most radical reduction in callcounts we've had in a few years. Has been there a decision on enabling the C extensions by default in 0.7, or is that still too controversial? Regards, Wichert. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] SQLAlchemy 0.6.6 Released
Happy New Year, SQLAlchemy 0.6.6 is now available. This release features
another long list of tweaks, fixes, and small enhancements, piling up since our
last release in October.
The 0.6 series is not surprisingly our most successful series ever, with SQLA
0.6.5 racking up 36,000 downloads from Pypi in a period of 76 days,
approximately 15K per month, plus about 2K a month from Sourceforge.
The majority of my time is now spent developing 0.7, which is nearly ready for
beta releases pending a few more little features I'd like to try to get in.
0.7 is really exciting with its new event API, lots of other nice touches and
of course the most radical reduction in callcounts we've had in a few years.
0.6.6 is primarily a bugfix release and includes important fixes to the C
extensions, the unit of work, subquery eager loading, obscure edge cases with
pretty much all of the major dialects, as well as a kick in the pants to
SQLSoup.
See the full changelog and download SQLAlchemy 0.6.6 at:
http://www.sqlalchemy.org/download.html
0.6.6
=
- orm
- Fixed bug whereby a non-"mutable" attribute modified event
which occurred on an object that was clean except for
preceding mutable attribute changes would fail to strongly
reference itself in the identity map. This would cause the
object to be garbage collected, losing track of any changes
that weren't previously saved in the "mutable changes"
dictionary.
- Fixed bug whereby "passive_deletes='all'" wasn't passing
the correct symbols to lazy loaders during flush, thereby
causing an unwarranted load. [ticket:2013]
- Fixed bug which prevented composite mapped
attributes from being used on a mapped select statement.
[ticket:1997]. Note the workings of composite are slated to
change significantly in 0.7.
- active_history flag also added to composite().
The flag has no effect in 0.6, but is instead
a placeholder flag for forwards compatibility,
as it applies in 0.7 for composites.
[ticket:1976]
- Fixed uow bug whereby expired objects passed to
Session.delete() would not have unloaded references
or collections taken into account when deleting
objects, despite passive_deletes remaining at
its default of False. [ticket:2002]
- A warning is emitted when version_id_col is specified
on an inheriting mapper when the inherited mapper
already has one, if those column expressions are not
the same. [ticket:1987]
- "innerjoin" flag doesn't take effect along the chain
of joinedload() joins if a previous join in that chain
is an outer join, thus allowing primary rows without
a referenced child row to be correctly returned
in results. [ticket:1954]
- Fixed bug regarding "subqueryload" strategy whereby
strategy would fail if the entity was an aliased()
construct. [ticket:1964]
- Fixed bug regarding "subqueryload" strategy whereby
the join would fail if using a multi-level load
of the form from A->joined-subclass->C [ticket:2014]
- Fixed indexing of Query objects by -1. It was erroneously
transformed to the empty slice -1:0 that resulted in
IndexError. [ticket:1968]
- The mapper argument "primary_key" can be passed as a
single column as well as a list or tuple. [ticket:1971]
The documentation examples that illustrated it as a
scalar value have been changed to lists.
- Added active_history flag to relationship()
and column_property(), forces attribute events to
always load the "old" value, so that it's available to
attributes.get_history(). [ticket:1961]
- Query.get() will raise if the number of params
in a composite key is too large, as well as too
small. [ticket:1977]
- Backport of "optimized get" fix from 0.7,
improves the generation of joined-inheritance
"load expired row" behavior. [ticket:1992]
- A little more verbiage to the "primaryjoin" error,
in an unusual condition that the join condition
"works" for viewonly but doesn't work for non-viewonly,
and foreign_keys wasn't used - adds "foreign_keys" to
the suggestion. Also add "foreign_keys" to the
suggestion for the generic "direction" error.
- sql
- Fixed operator precedence rules for multiple
chains of a single non-associative operator.
I.e. "x - (y - z)" will compile as "x - (y - z)"
and not "x - y - z". Also works with labels,
i.e. "x - (y - z).label('foo')"
[ticket:1984]
- The 'info' attribute of Column is copied during
Column.copy(), i.e. as occurs when using columns
in declarative mixins. [ticket:1967]
- Added a bind processor for booleans which coerces
to int, for DBAPIs such as pymssql that naively call
str() on values.
- CheckConstraint will copy its 'initially', 'deferrable',
and '_create_rule' attributes within a copy()/tometadata()
[ticket:2000]
- engine
- The "unicode warning" against non-unicode
