On Fri, Jul 30, 2010 at 2:57 PM, Jerome Leclanche wrote:
> [2] People who do have ideas and do write code, but still get rejected
> because their ideas don't conform to whatever the core devs need in
> their websites.
I don't think that's a fair criticism at all.
> ...
> Nice job scaring that po
On Wed, Mar 10, 2010 at 7:51 AM, Brian Rosner wrote:
>
> On Mar 10, 2010, at 7:16 AM, Joan Miller wrote:
>
>> It's a disaster from the maintenance view point. If it were not so,
>> then people would not be proposing to refactor the settings as has
>> been made in Pinax, or from multiple posts so m
On Sat, May 16, 2009 at 1:42 PM, Richard Davies
wrote:
>
> My question is effectively the same as asking if the test suite passed
> on Oracle between [8314] in August 2008 and [10022] in March 2009.
>
> I assume that it must have passed during those six months (Django 1.0
> was [8961] in Septembe
On May 6, 2009, at 8:50 PM, Karen Tracey wrote:
> On Wed, May 6, 2009 at 10:34 PM, Leo Soto M.
> wrote:
>
> While testing the django-jython oracle backend I get an ugly failure
> on model_forms_regress,
Yes, I saw this too. I'll check in a fix tomorrow a.m. if no one
beats me to it.
>
On Jan 22, 2009, at 9:23 PM, catsclaw wrote:
>
> On Jan 22, 12:12 am, Jacob Kaplan-Moss
> wrote:
>> Why don't we start over here: what is the problem? What did you try
>> do
>> do? What did you expect to happen? What actually happened?
>
> Here's another problem I'm stuck at. I'm trying
As another data point, our nightly run of the test suite against
Oracle just completed. We see the same test failures we had
previously--nothing new--but it was *much* faster as hoped.
Python 2.5, Django 1.0.x: 24510 secs.
Python 2.5: Django trunk: 3024 secs.
Previously, trunk took about ten mi
On Aug 25, 10:51 am, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> I just noticed that the MySQL backend also fails on this get_or_create
> test. It is returning an OperationalError instead of an IntegrityError.
> Looks like MySQL returns errno 1364 (ER_NO_DEFAULT_FOR_FIELD) in this case
> but this
side the oracle backend. Let me know if
you think that's acceptable.
On Aug 23, 10:47 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sat, 2008-08-23 at 08:07 -0700, Matt Boersma wrote:
>
> [...]
>
> > However, I grep'ed the Django source and found t
On Aug 22, 5:56 pm, Justin Bronn <[EMAIL PROTECTED]> wrote:
> FYI, r8471 fixed my problems and all Oracle GeoDjango tests pass
> again. Thanks.
That's good news, Justin--thanks for verifying! (I have access to 9i
and 10g servers--not just XE--but spatial isn't licensed for any of
them so I had
I noticed that in the get_or_create test case, Oracle fails because
the cx_Oracle database driver raises a DatabaseError, not a more
specific IntegrityError, when an INSERT lacks a required field.
(Malcolm anticipated this in his commit message for r8450.) Looking
at the C code for the driver, it
On Aug 20, 1:01 pm, Justin Bronn <[EMAIL PROTECTED]> wrote:
> > Item.objects.dates('created', 'day')[0]
> > DatabaseError: ORA-00923: FROM keyword not found where expected
>
> That's the exact error that's giving me problems -- I think it's one
> of the same issue as I'm having. It's because of t
On Aug 20, 10:50 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> There's one SQL syntax error that I can't fix, however (in
> regressiontests/queries/models.py). I'll look at the pickling issue
> there, but the SQL problem I can't debug.
If you mean this one:
Item.objects.dates('created', 'd
Hi Justin,
Sorry, I should have run the gis tests as well. (Is that Malcom
snickering I hear? I'm chastened.)
Did GeoDjango break in r8426 then, as Oracle in general did? That's
where extra_select changed. I can see how our new code in r8445
breaks on your function column.
I'll look at it t
lause.
This seems to fix most of the failures. I'll check it in soon when
I'm sure it's not causing any new problems.
On Aug 18, 2:20 pm, "Ramiro Morales" <[EMAIL PROTECTED]> wrote:
> Matt,
>
> On Mon, Aug 18, 2008 at 4:04 PM, Matt Boersma <[EMAIL PROTE
This is just a heads up since clearly some committers must be unaware:
checkins of the last two days have created 27 (yes, twenty-seven) new
test case failures for Oracle. I had been working on cleaning up the
existing few failures for the Oracle backend, but unless those who
actually committed t
That's pretty cool! I've attempted this in the past, but always ended
up with test case failures, and didn't see any speedups, so I
abandoned it. I'll try this out when I have time.
Could someone repackage it as a proper patch attached to ticket #7732?
I think I'd rather see it folded into the
On Oct 3, 6:23 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Oracle changes on the queryset-refactor branch are probably going to be
> about the last thing to land on that branch because it's very time
> consuming to test and work with for me.
It sure is--we tend to run only single tests du
That fixed it--I got the confirmation email immediately this time
after registering. I'll close #5579. Thanks, Jacob.
On Oct 1, 2:20 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> OK, it should be fixed for real this time -- emails are now being sent
> from "[EMAIL PROTECTED]"
>
> Matt, c
On Sep 26, 8:38 am, Barry Pederson <[EMAIL PROTECTED]> wrote:
> Matt Boersma wrote:
> > In reviewing bug #5579 (seehttp://code.djangoproject.com/ticket/5579),
> > I discovered I never receive the confirmation email from Trac at
> >http://www.djangoproject.com/accounts/
In reviewing bug #5579 (see http://code.djangoproject.com/ticket/5579),
I discovered I never receive the confirmation email from Trac at
http://www.djangoproject.com/accounts/register/. I've tried four
times since Sunday, using two email addresses in different domains. I
can't actually verify th
On Sep 21, 2007, at 2:22 PM, SmileyChris <[EMAIL PROTECTED]> wrote:
>
> On Sep 19, 11:44 pm, Ned Batchelder <[EMAIL PROTECTED]> wrote:
>> Now we just need to get someone to put it on the site...
>
> +1. Easy to do, looks good.
+1. It's excellent.
--~--~-~--~~~---~
On Jun 1, 8:50 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> ... Is there perhaps a VMWare
> image of a pre-installed Oracle that I can test this stuff against?
Oracle had a developer program called "Oracle By Example" (OBE) that
provides a VMware image with RedHat, Oracle 10gR2 RAC, etc.
On May 11, 8:37 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> ...
> So should the Oracle branch be ignoring the null attribute when
> blank=True and assuming null=True in that case?
I think that's reasonable. It may mean a couple of unit tests fail,
so we can either modify them or at leas
I had purposely let this thread dangle, hoping Malcolm or Adrian or
Jacob might weigh in and decide the "db_tablespace" minor controversy.
But I hope this unresolved issue isn't perceived as holding up
integration of the Oracle patch. I don't think it should. At worst,
we could strip out the "d
s.
>
> For my 2c worth, if this cannot already be done by the current Oracle
> database framework, I think that would be a beneficial addition if
> only to provide completeness to the option to assign tablespaces.
>
> Regards
> Ben Khoo
>
> On Apr 21, 1:54 am, Matt Boersma
pdate.
Matt
On Apr 20, 10:03 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On 4/19/07, Matt Boersma <[EMAIL PROTECTED]> wrote:
>
> > The "boulder-oracle-sprint" branch is ready to come home.
>
> Congrats, guys! Thanks to all of you for your h
one, so
> kudos go to ring leader Matt Boersma, the intrepid Ian Kelly, Eric
> Dobbs, Matt Drew, Michelle Cyr, and Mitch Smith for making this
> happen.
>
> And a special thanks to you for coming out on an early flight from
> Lawrence and working with us in Boulder on Saturday, No
The "boulder-oracle-sprint" branch is ready to come home.
We made a wiki page describing the goals and status of the code (quick
summary: Oracle works and we think it's done, unless you tell us
otherwise). Attached to that page is a patch against rev 5036 of the
trunk. See here:
http://code.dja
Frank, I've been doing as much maintenance and bug fixing as I can on
the boulder-oracle-sprint branch. I test against 9i as well as 10g
XE.
If you could do as James suggests and post a detailed bug report at
http://code.djangoproject.com/, I'll take a look and get it fixed.
thanks,
Matt
On M
At the Django-Oracle sprint a couple months ago, we discussed having an
optional "tablespace" parameter when defining models, but not a
separate one for the index tablespace. We didn't get around to
implementing it.
In Oracle-land, your requirement is actually common, not unique. I
think it's
Andreas, I finally got around to applying and testing your patch.
Thanks very much--it makes the Oracle test environment much more
flexible.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django
developers" group
This is now fixed in the current boulder-oracle-sprint branch, as of
changeset [4277].
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-develope
Here is the current status of Oracle support:
- Some of the backend files are already in subversion trunk, but not
enough to make it functional. Don't bother testing (or patching)
Oracle support in the trunk--the branch is where the action is.
- Some Colorado developers, along with Jacob Kaplan-
33 matches
Mail list logo
