Queryset-refactor branch has been merged into trunk

[Malcolm Tredinnick]

I merged queryset-refactor into trunk just now. This was changeset
r7477.

There are still a couple of enhancements to do, but I've decided they're
not worth holding up the entire branch for. I can just as easily do them
on trunk.

Thanks to everybody who reported bugs and tested things. Thanks
especially to Justin Bronn and Ian Kelly for lots of patches and testing
to get the Oracle backend up to scratch on the branch.

Detailed list of changes is in the branch's wiki page ([1]) and if
you're interested in seeing the documentation additions and changes, you
can view [2].

[1] http://code.djangoproject.com/wiki/QuerysetRefactorBranch
[2] http://code.djangoproject.com/changeset?new=django%2Ftrunk%2Fdocs%
407477&old=django%2Ftrunk%2Fdocs%407411

No more bugs should now be reported against the queryset-refactor
version. The branch is closed.

Regards,
Malcolm

--
On the other hand, you have different fingers.
http://www.pointy-stick.com/blog/

[Prairie Dogg]

Malcom,

Thanks so much for your tremendous effort and success on this!

You rock!

On Apr 26, 11:04 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:

[Prairie Dogg]

Malcolm: Sorry - it's late over here, didn't mean to mis-type your
name.

File this and previous under: damn-life's-work-with-faint-praise

[Eric Abrahamsen]

Mmmm... model inheritance... multiple OneToOne fields.... mmm....

Thanks for all your hard work, Malcolm! Beers are owed to you!

[prote...@gmail.com]

I was just thinking last night about how nice it will be to get this
into trunk and there it is! :) Now I'm thinking how nice it would be
for Malcolm to send me $10,000... will let you all know how it works
out.

Seriously - great work and congrats on what must be a relief to
finally get to the point where everyone can start using and leveraging
it. One question - does this provide any potential performance
improvements by reducing the number of db accesses for some queries or
does all that occur a level below where this change set impacts? Have
you attempted any speed comparisons?

Thanx!

-- Ben Scherrey

On Apr 27, 10:04 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:

[Thierry]

What's the current opinion about integrating sql alchemy into the
backend of django's ORM?

[Simon Willison]

On Apr 27, 8:48 am, Thierry <thierryschellenb...@gmail.com> wrote:
> What's the current opinion about integrating sql alchemy into the
> backend of django's ORM?

There's an active project to do exactly that hosted here:

http://gitorious.org/projects/django-sqlalchemy/

Some of the features in queryset-refactor are designed to make this
kind of thing easier, but it's still a major undertaking.

[kamil]

I wish god will pay you Malcolm. ;)
It's a great news for django community.
thanx

[TP]

Great! I tried trunk as of a few minutes ago with a moderately
complicated project I have using MySQL and everything seems to work
fine. Will keep testing it over the next few days and report any
problems.

On Apr 26, 11:04 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:

[sserrano]

Thanks for the great work!!!

On Apr 27, 12:04 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:

[simonbun]

So qs-rf hit trunk and was merged into nfa on the same day! That's
excellent news, both for me and for django. Thanks so much for your
efforts Malcolm (and Brosner for the quick merge)!

regards,
Simon

[Julien]

Thanks Malcolm for this huge contribution! I switched a quite big live
project to the new trunk and it's working really well so far.

Cheers,

Julien

[Matt Hoskins]

On Apr 27, 4:04 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:

> I merged queryset-refactor into trunk just now. This was changeset
> r7477.

Thanks for all your hard work Malcolm on queryset-refactor, it's much
appreciated!

Regards,
Matt

[hiwd]

malcom,

thanks much for your hard work on this bad boy!

I've already @ioubeer ya on twitter. so the next time you're in nyc,
i'm buying.

much appreciated, cheers!

On Apr 26, 11:29 pm, Prairie Dogg <wiley.kest...@gmail.com> wrote:

[Juanjo Conti]

Malcolm Tredinnick escribió:

> I merged queryset-refactor into trunk just now. This was changeset
> r7477.

Could you give me a url where new features are explained?
Is this backwards compatible or should I svn up with care?

Thanks

Juanjo
--
mi blog: http://www.juanjoconti.com.ar

[James Bennett]

On Mon, Apr 28, 2008 at 8:32 AM, Juanjo Conti <jjc...@gmail.com> wrote:
> Could you give me a url where new features are explained?
> Is this backwards compatible or should I svn up with care?

Well, there's the wiki page Malcolm linked up in his original post...

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

[Don Spaulding II]

Malcolm Tredinnick wrote:

I merged queryset-refactor into trunk just now. This was changeset
r7477.

Thanks for all of your effort on this, Malcolm.


Malcolm's Amazon Wishlist:
http://www.amazon.com/gp/registry/registry.html?ie=UTF8&type=wishlist&id=1VB5A16R2KV0T

[Craig Ogg]

w00t!

Not sure where to point this out, but anyone using the full text
search implementation from Mercurytide[1] will get the following
error:

django/db/models/query.py
line c = klass(model=self.model, query=self.query.clone())
"__init__() got an unexpected keyword argument 'query'"

The sample classes they define are subclassing without handling *args
and *kwargs. This is easy to resolve by adding them:

class SearchManager(models.Manager):
def __init__(self, index_column, *args, **kwargs):
super(SearchManager, self).__init__(*args, **kwargs)
self._index_column = index_column

Craig
[1] http://www.mercurytide.co.uk/whitepapers/django-full-text-search/

[davenaff]

Awesome work. Thanks!

[Kevin Monceaux]

On Sun, 27 Apr 2008, simonbun wrote:

> So qs-rf hit trunk and was merged into nfa on the same day! That's
> excellent news, both for me and for django. Thanks so much for your
> efforts Malcolm (and Brosner for the quick merge)!

I'll second that. I've been running against the nfa branch. I just
updated to pull in the qs-rf changes. I only had to make a couple of
minor code changes to my site in cases where I was ordering by fields from
another model. I like the new syntax much better than having to use the
underlying table names. Congratulations to all involved!!!!!!

Kevin
http://www.RawFedDogs.net
http://www.WacoAgilityGroup.org
Bruceville, TX

Si hoc legere scis nimium eruditionis habes.
Longum iter est per praecepta, breve et efficax per exempla!!!

[pemdas]

Thanks for the post! It would have taken me hours to figure out where
to start looking when this error first came up. I made the change to
my SearchQuerySet subclass instead and it works also. I didn't make
the change to SearchManager. My code looks like this if interested.

class SearchQuerySet(models.query.QuerySet):
def __init__(self, model=None, fields=None, *args, **kwargs):
super(SearchQuerySet, self).__init__(model, *args, **kwargs)
self._search_fields = fields

Also, I was reading the docs on the queryset-refactor branch (http://
code.djangoproject.com/wiki/
QuerysetRefactorBranch#Backwardsincompatiblechanges) and there is a
note at the bottom that says the params argument for extra() will now
only work for the where clause. Since Mercurytide's solution uses
params for both select and where I would expect this to also be a
problem. Surprisingly it still works.

It also works with the new solution which looks like this
select_params=[query],params=[query]

instead of
params=[query,query]

-Matt

[pemdas]

The above post is in reference to Craig Ogg's post on using the
Mercurytide FullText searching.