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
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
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
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
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
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
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
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
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
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
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
Let me also bring up once again, that this is what all the other major DB
layers that I've looked at do. So it doesn't seem like it's a bad solution
at all.
On Sun, May 4, 2008 at 11:11 PM, James Bennett <[EMAIL PROTECTED]>
wrote:
>
> On Mon, May 5, 2008 at 1:00 AM, David Cramer <[EMAIL
On Mon, May 5, 2008 at 1:00 AM, David Cramer <[EMAIL PROTECTED]> wrote:
> This may not directly solve the problems that are being referred to, but it
> was a bug fix none the less, and I believe it is relative to the issue at
> hand.
I never said it wasn't a *possible* solution, I just said it
Let's not quote me if you don't understand what I'm saying.
The patch we applied at Curse did the following (and solved some extra
queries):
- Added an _is_stored attribute on instances, default value was None
- _is_stored became True upon an instance retrieval via a QuerySet
- _is_stored became
20 matches
Mail list logo
