On Tue, May 6, 2008 at 10:12 AM, Collin Grady <[EMAIL PROTECTED]> wrote:
>
> SmileyChris said the following:
>
> > You were using a new feature (albeit the wrong one) so that's not
> > really a backwards incompatible issue, is it?
>
> The old ObjectPaginator class is going away though, isn't it
SmileyChris said the following:
> You were using a new feature (albeit the wrong one) so that's not
> really a backwards incompatible issue, is it?
The old ObjectPaginator class is going away though, isn't it? That sounds
like backwards incompatible to me ;)
--
Collin Grady
Computer programmer
Well it's deprecated. If nothing else, can we have a "OMGBIGCHANGES"
wiki page? :)
In regards to features. I could make quite a few suggestions for the
paginator based on my use-cases at Curse and other projects. The new
one is a big improvement, but I find that I still can't use it without
subcl
You were using a new feature (albeit the wrong one) so that's not
really a backwards incompatible issue, is it?
On May 6, 1:55 pm, David Cramer <[EMAIL PROTECTED]> wrote:
> Can someone add it to the BackwardsIncompatibeChanges page?
>
> I saw the warning, and briefly skimmed over the page and swi
Can someone add it to the BackwardsIncompatibeChanges page?
I saw the warning, and briefly skimmed over the page and switched to
Paginator. To my suprise, there was a little clause at the bottom
saying "USE QUERYSETPAGINATOR" which I didn't notice. You can guess
what I was thinking when I saw it
Hi, Rahein,
The Firebird patch and backend is against latest Django trunk and
depends on the newest Django features, especially new QuerySet/Query
classes. Please note that there are known bugs with very complex ORM
queries. It's also important to use the latest Firebird (> 2.0).
Earlier versions
Ahh that must be it, thanks. I am using 0.96.1. I am about to head out for
the day, but I will try it with the current trunk tomorrow.
Thanks for your help Ian.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django
On Mon, May 5, 2008 at 1:53 PM, Rahein <[EMAIL PROTECTED]> wrote:
>
> I am really learning the internals of Django.
>
> I changed line 208 in db\models\base.py from:
>
> cursor.execute("SELECT 1 FROM %s WHERE %s=%%s LIMIT 1" % \
>
> to:
>
> cursor.execute("SELECT 1 FROM %s WHERE %s=%%s ROWS 1
Thanks for the quick reply Tim, see my other posts.
FB is probably the most SQL99 standard SQL DB, so usually the standard
statements work. I think FB 2.1 is going to support all 3 different
limiting syntax. I changed it to work with ROWS.
On May 5, 2:49 pm, Tim Chase <[EMAIL PROTECTED]> wrote:
I am really learning the internals of Django.
I changed line 208 in db\models\base.py from:
cursor.execute("SELECT 1 FROM %s WHERE %s=%%s LIMIT 1" % \
to:
cursor.execute("SELECT 1 FROM %s WHERE %s=%%s ROWS 1" % \
Shouldn't that FB patch have fixed this type of stuff? Did I apply it
wrong?
--
>> The real problem is when I try to access the database. I get
>> stack trace below. It looks like it is trying to use the
>> LIMIT keyword incorrectly.
As best I can tell, Firebird doesn't support the SELECT ... LIMIT
x OFFSET y" notation, but rather uses "SELECT FIRST x [SKIP y]
..." as detai
Well I changed \backends\firebird\base.py to print out the SQL
statement, it is:
SELECT 1 FROM "BOOKS_PUBLISHER" WHERE "ID"=%s LIMIT 1
Instead of LIMIT it should says ROWS. Any idea how to fix this?
--~--~-~--~~~---~--~~
You received this message because you ar
Sphinx has very good documentation, and a full implementation in
Django is available: http://code.google.com/p/django-sphinx/
On May 5, 7:05 am, mrts <[EMAIL PROTECTED]> wrote:
> Excellent. Looking forward for the finished project!
>
> On May 5, 4:50 pm, Ben Firshman <[EMAIL PROTECTED]> wrote:
>
I am trying to get Django working with Firebird as the database
backend. I have done some searching and found kinterbasdb and the
firebird patch to get it to work with Django.
I am trying to follow the free books tutorial, but having problems.
First the creation of the tables in the DB didn't wo
Excellent. Looking forward for the finished project!
On May 5, 4:50 pm, Ben Firshman <[EMAIL PROTECTED]> wrote:
>
> For everything:
>
> results = djangosearch.search("query")
>
> or more specific:
>
> results = djangosearch.search("query", models=[Foo, Bar])
--~--~-~--~~~
On 5 May 2008, at 14:34, mrts wrote:
> Looks nice, except one (probably most common) use case -- search over
> all indexed fields in all models that have them.
>
> E.g. the following is both cumbersome and ineffective:
>
> class Foo(models.Model):
> x = models.CharField(max_length=255)
> index
> It currently works something like this:
>
> from django.db import models
> from djangosearch import ModelIndex
>
> class Article(models.Model):
> title = models.CharField(max_length=255)
> date = models.DateField()
>
> index = ModelIndex(fields=['title', 'date'])
>
> def __unicod
17 matches
Mail list logo
