SQLAlchemy 0.4 MERGED TO TRUNK

[Michael Bayer]

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.

[svilen]

one suggesstion / request.

As your changing everything anyway, can u replace all important {} and
dict() with some util.Dict, and set() with util.Set?
util.Ones can point to dict/set.
The reason is so they can be further globally replaced by user with
OrderedOnes, for example to achieve repeatability - tests etc.

example ones are:
MetaData.tables
unitofwork.UOWTransaction.dependencies
unitofwork.UOWTask.objects
mapperlib.Mapper.save_obj(): table_to_mapper = {}
mapperlib.Mapper._compile_properties(): self.__props = {}
sqlalchemy.topological.QueueDependencySorter.sort(): nodes = {}
these give 90% repeatabliity, but i could not make it 100%. )-:

[michael]

On Fri, 27 Jul 2007 04:36:50 -0000
Michael Bayer <zzz...@gmail.com> wrote:

>
> Hey ho -
>
> after around 400 revisions the 0.4 branch is merged to trunk:
>
> http://svn.sqlalchemy.org/sqlalchemy/trunk

Congratulations on the progress for the next generation! That goes for
you, Michael Bayer, and the team working so hard on this project. Thank
you for sharing all that hard work with everyone.

I wonder if you ever imagined that a project started to 'scratch an
itch' would ever blossom into something so huge. (in lines of code,
documentation.. and time spent!)

As only one measure; the quantity of posts on this lists; shows that a
lot of people benefit from and depend on your work. While I am not
making any money off your blood, sweat, and tears; I still appreciate
your work. I just made a donation using the paypal link on the home
page. Maybe others can show their appreciation, too.

Thanks again.

--

michael

[svilen]

here the changes i needed to get dbcook (abstraction layer over SA),
and its tests going to some extent (70% - relations and expressions
are broken):
- BoundMetaData -> MetaData - lots (15)
- metadata.engine.echo=True - lots (14)
Whats the difference between create_engine's echo=boolean and
MetaData's echo=boolean ??
- import sqlalchemy.orm - i need mostly 4 things off that, but on
lots of places (35): create_session, mapper, relation, clear_mappers.
several more things like polymorphic_union, class_mapper etc on
single occasions (2-3)
*** above 3 are very common - but easy - about each SA-using file
- query.get_by_whatever - geee, i didnt know i use it (3)
- binaryExpression.operator - operator.xx-builtin and not text (1)

- type_ vs type - too bad, now i need a key-faking dict. (3+2)
why, u're afraid type() will become reserved word or what?

- mapper.polymorphic_identity without polymorphic_on - i have these,
assuming that having no polymorphic_on ignores anything about
polymorphism anyway... now it becomes very tricky as for D(C(B(A)))
when making D, it does not really know if was A polymorphic or not...
it has to get base_mapper and check its polymorphic_on... (3)

- Select (and i guess Clause) lost its accept_visitor

- sql.compile traversing takes about more recursion levels than
before - not really a problem

- InstrumentedList gone = my append(key=value) hack gone.. must find
the new way (1)
- expression translator - simply forget, it relies on way to many
internal hooks, and should be rethinked as of new Query and stuff.

The hack4repeateability stopped working :-) which was expected.
Same about the 'nicer echo of select' hack. ticket/497 - u forgot me..

So: the bulk of changes, line-count-wise is cosmetical; but anything
depending on internal hooks/hacks is ... near-dead.

i'm not sure if to go 0.4 or stay 0.3, or try being backward
compatible. or add a branch. i did backward compatibility before, but
now there are way too many changes now.

ciao
svil

>On Friday 27 July 2007 07:36:50 Michael Bayer wrote:

> Note that this version has some backwards incompatibilities with 0.3
>

[Michael Bayer]

patch would be helpful

[Jonathan Ellis]

I'd want to make sure this didn't hurt performance first. (Seems
innocuous enough, but if it's in any sort of inner loop the extra hash
lookup might be noticeable.)

[sdo...@sistechnology.com]

On Friday 27 July 2007 19:48:51 Jonathan Ellis wrote:
> I'd want to make sure this didn't hurt performance first. (Seems
> innocuous enough, but if it's in any sort of inner loop the extra
> hash lookup might be noticeable.)

if lookup is made once in the start of function, should be okay.
which inner loops are so sensitive?

btw there were so many redundantly made dicts and lists before...
my profiling showed (in february or march) that redundant
function-calls kill performance, all else goes negligible.

[sdo...@sistechnology.com]

i'll do it after 2 weeks, ciao

[Michael Pearson]

Hi,

Are there plans to print warnings when deprecated methods are used?

I've just spent the morning future-proofing our code against SA 0.4
and would have found this useful. I may attempt a patch myself, if
people agree that it'd be a good idea.

Regards,

--
Michael Pearson

[Michael Bayer]

ive considered this so if someone is willing to submit a patch that
would be great.

[Jonathan Ellis]

I can probably do this tonight.

How many people are still using 2.3? Decorator syntax would be nice for this.

Also it would be nice to not have to remember that I can't use genexps
in SA code.

But 2.3 is a pretty good base, I don't miss much else from 2.4. :)

[Michael Bayer]

On Jul 30, 2007, at 1:22 PM, Jonathan Ellis wrote:

>
> I can probably do this tonight.
>
> How many people are still using 2.3? Decorator syntax would be
> nice for this.

a lot. no decorators for now.

>
> Also it would be nice to not have to remember that I can't use genexps
> in SA code.

it sure would. maybe in another 6 months we'll take a poll again.

[Jorge Godoy]

Michael Bayer wrote:

> a lot. no decorators for now.

Not even the way we did on TurboGears that mimics the PEAK decorators? This
way, people can use "@decorator(param)" on Python 2.4+ and can
use "[decorator(param)]" on Python 2.3. At the same place (before the
method / function declaration).

[Michael Bayer]

can i have an example

[Marco Mariani]

Michael Bayer ha scritto:

> can i have an example
>

http://trac.turbogears.org/browser/branches/1.0/turbogears/database.py?rev=2320

281 [run_with_transaction.when("_use_sa()")]
282 def sa_rwt(func, *args, **kw):
283 log.debug("New SA transaction")
284 transaction = session.create_transaction()
285 try:
[...]

[Jorge Godoy]

Marco Mariani wrote:

Thanks Marco!

Since I only have limited access to email during the day, I couldn't reply
before.