On Fri, Nov 21, 2008 at 1:05 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> I won't use defer, and I won't recommend people use it. I think it's
> not good practice. It's like using .select_related() implicitly. You
> really need to explicitly pass things around in order ot keep things
> performant
at the OracleQuery class in the oracle backend to see how
the same problem was solved there. Specifically, look at the as_sql
and resolve_columns methods.
Hope that helps,
Ian Kelly
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the G
On Mon, Dec 15, 2008 at 4:23 AM, Ambrish Bhargava
wrote:
> Hi,
>
> While working on the new backend support for DB2, I found that in
> CREATE TABLE DDL generation, it contains some non-standard SQL syntax.
>
> Here is one example of model.
>
> class User(models.Model):
>first_name = models.Ch
On Mon, Jan 5, 2009 at 9:21 AM, Alex Gaynor wrote:
> The one's that are a result of Oracle not returning a Decimal can be solved
> be inserting "..." before and after the number, in placeess of explicitly
> saying Decimal(unless of course this is actually a typecasting issue in
> Django itself, i
On Tue, Jan 6, 2009 at 12:14 AM, Ian Kelly wrote:
> On Mon, Jan 5, 2009 at 9:21 AM, Alex Gaynor wrote:
>> The SQL command not properly ended appears to be the result of an annotate
>> call followed by a call to aggregate(). I don't have a clue what causes
>> that as I
On Wed, Jan 7, 2009 at 8:55 AM, Karen Tracey wrote:
> On Wed, Jan 7, 2009 at 9:46 AM, Russell Keith-Magee
> wrote:
>>
>> I've just pushed some updates to Github that should hopefully fix the
>> problems that have been reported (ORA-00933, ORA-00923 and ORA-00972
>> and the decimal/datetime conve
On Wed, Jan 7, 2009 at 7:46 AM, Russell Keith-Magee
wrote:
> There is some potential for further refactoring here, especially with
> regards to the decimal/datetime conversion routines. The Oracle
> DatabaseOperations.convert_values() function that I added for
> aggregate support is an almost per
On Thu, Jan 8, 2009 at 6:31 PM, Alex Gaynor wrote:
> The actual implementation issue arrise with the usage of F() for related
> fields in update queries. Specifically one of my concerns was the
> portability of the SQL. I spoke with Michael Trier this afternoon and it
> appears to me that the S
On Fri, Jan 9, 2009 at 2:09 PM, Ian Kelly wrote:
> On Thu, Jan 8, 2009 at 6:31 PM, Alex Gaynor wrote:
>> The actual implementation issue arrise with the usage of F() for related
>> fields in update queries. Specifically one of my concerns was the
>> portability of t
On Fri, Jan 9, 2009 at 2:19 PM, Alex Gaynor wrote:
> Well the idea is to do that for all DB engines(since it's the only portable
> option), so while Oracle may optimize it correctly I very much doubt MySQL
> does :) . Is the multiple-set portable to other dbs(in any event I think it
> would come
On Mon, Jan 12, 2009 at 5:32 PM, V.Prudnikov wrote:
>
> Is there any reason why automatic primary key not set to UNSIGNED by
> default?
Not sure. Is there any reason why it would be necessary or useful to
prevent them from being negative?
Ian
--~--~-~--~~~---~--~--
On Mon, Jan 12, 2009 at 6:11 PM, Alex Gaynor wrote:
>
>
> On Mon, Jan 12, 2009 at 8:09 PM, Ian Kelly wrote:
>>
>> On Mon, Jan 12, 2009 at 5:32 PM, V.Prudnikov wrote:
>> >
>> > Is there any reason why automatic primary key not set to UNSIGNED by
>
On Wed, Jan 14, 2009 at 10:54 AM, Karen Tracey wrote:
> I'm also seeing failures when using Oracle as the backend, many tracebacks
> that end with:
>
> File "d:\u\kmt\django\aggregation\django\db\backends\oracle\query.py", line
> 69, in convert_values
> elif value is not None and field.get_in
On Wed, Jan 14, 2009 at 12:20 PM, Ian Kelly wrote:
> I'm seeing the same errors using the tarball snapshot. All but the
> last one are fixed by the attached patch.
By "the last one" I actually mean the final failure where a float is
expected but
On Wed, Jan 14, 2009 at 4:03 PM, Russell Keith-Magee
wrote:
>
> On Thu, Jan 15, 2009 at 4:21 AM, Ian Kelly wrote:
>>
>> On Wed, Jan 14, 2009 at 12:20 PM, Ian Kelly wrote:
>>> I'm seeing the same errors using the tarball snapshot. All but the
>>>
On Thu, Jan 15, 2009 at 1:58 AM, Jan Bednařík wrote:
>
> On Wed, Jan 14, 2009 at 6:51 PM, Sebastian Bauer wrote:
>>
>> Hi
>>
>> I think it's a bug, but maybe im wrong:
>>
>>
>> print Categories.objects.count()
>> >>0
>> new_obj = Categories.objects.create(name="test")
>> instance_1 = Categories
On Thu, Jan 29, 2009 at 4:14 AM, Russell Keith-Magee
wrote:
>
> Hi all,
>
> With [9792], I've committed F() query expressions to trunk. For
> details, see the docs:
Hi Russell,
First, my apologies for not testing this with Oracle sooner. It
appears that nobody else tested it either, because th
On Fri, Jan 30, 2009 at 8:43 PM, Russell Keith-Magee
wrote:
> Can you clarify what you mean here - is it case of 'doesn't have these
> operators in any form', or 'has these operators, but uses different
> characters/functions? You answer this below for the bitwise operators,
> but what about %? H
On Tue, Feb 17, 2009 at 7:40 AM, M N Islam Shihan wrote:
>
> Hi,
>
> Please go through the comments of the blog post you are referring and you'll
> understand why, how and where to use the django ORM.
>
> Regards,
> Shihan
Something I've just noticed here. One of the comments links to the
docum
On Tue, Feb 17, 2009 at 3:00 PM, Jeremy Dunck wrote:
>
> On Tue, Feb 17, 2009 at 3:52 PM, James Bennett wrote:
>>
>> On Tue, Feb 17, 2009 at 7:40 AM, NitinHayaran wrote:
>>> Today i read this article and was wondering whether django orm is
>>> really that bad.
>>>
>>> http://dayhacker.blogspot.
I'd like to request some extra sets of eyes for the patch in ticket #10290.
The summary: from r9838 on, I'm getting aggregation_regress test
failures in Oracle, apparently because annotations with extra selects
are adding the extra select aliases into the group by list. This
produces invalid SQL
On Tue, Feb 17, 2009 at 5:01 PM, Russell Keith-Magee
wrote:
> Out of interest - where does Oracle fall on this one? Can you use
> aliases in a HAVING or ORDER BY?
Oracle only allows aliases in the ORDER BY clause.
>
>> If there are no concerns or potential gotchas with this approach, then
>> I'
On Tue, Feb 17, 2009 at 5:54 PM, Malcolm Tredinnick
wrote:
>
> Hi Ian,
>
> On Tue, 2009-02-17 at 16:05 -0700, Ian Kelly wrote:
> [...]
>> The solution that I'm proposing is to use the extra select expression
>> itself in the group by, rather than the alias. Thi
On Wed, Feb 18, 2009 at 11:53 PM, Malcolm Tredinnick
wrote:
> Any particular grounds for doing something spec-compliant feeling
> fragile to you, Ian? Having let this bounce around for 24 hours, I can't
> think of a strong reason not to do it.
Only the hazards of copying an arbitrary select expr
On Sun, Mar 1, 2009 at 8:25 AM, NewSpire wrote:
>
>> MySQL, if I recall correctly,
>> flat-out will not support this at all.
>
> Correct! MySQL definitely does not support multiple auto-increment
> fields. However, that is not what I'm talking about. I would just
> like the primary key require
On Thu, Mar 5, 2009 at 8:37 AM, Evgeniy Ivanov wrote:
>
> Hi!
>
> I have such code:
> "name = models.CharField(max_length=32)".
> Thus "blank=False and null=False" should be applied. But in DB this
> attr is nullable, and since oracle stores empty strings as null
> attribute created wrongly (' "N
On Thu, Mar 5, 2009 at 11:57 AM, Evgeniy Ivanov wrote:
>
>
>
> On Mar 5, 6:57 pm, Ian Kelly wrote:
>> On Thu, Mar 5, 2009 at 8:37 AM, Evgeniy Ivanov
>> wrote:
>>
>> > Hi!
>>
>> > I have such code:
>> > "name = models.CharFie
After r10003, Model.save() raises an error in Oracle if the model
includes a TimeField. The reason appears to be that save_base calls
TimeField.get_db_prep_save prior to passing the value on to the
queryset, which calls TimeField.to_python -- returning a time instance
-- and then passes the resul
On Mon, Mar 9, 2009 at 3:46 PM, Ian Kelly wrote:
> There may also be an argument for removing the seemingly redundant
> get_db_prep_save call from save_base. Any thoughts on that?
I should add that the main thing that concerns me about this fix is
that it would make save_base inte
On Fri, Mar 13, 2009 at 1:58 PM, Gregor Kling
wrote:
>
> Hello there,
>
> Regrettably the IPAddressField implementation is not what I expect :-(.
> Is there by any chance, the possibilty to have a solution that works for
> ipv4 *and* ipv6 in the near future ?
See ticket #811: http://code.django
On Fri, Mar 20, 2009 at 6:36 PM, pavel.schon wrote:
>
> Hi, I'v written IPAddressField that stores IPy.IP instances. Look at
> http://www.djangosnippets.org/snippets/1381/ and try it. Thanks for
> bugreports.
I'm afraid Oracle only supports 38 digits of precision for numeric
columns. Since this
On Sun, Mar 29, 2009 at 2:12 PM, Kurt Grandis wrote:
> http://code.djangoproject.com/ticket/9986
>
>
> This ticket proposes reconciling the code's parameter name, cull_frequency,
> with the docs' cull_probability; the ticket proposes standardizing on
> cull_probability, which I think would be mis
On Mon, Mar 30, 2009 at 2:22 PM, Marty Alchin wrote:
> Personally, I'd rather see an argument name that tries to tell users
> what to supply, rather than solely trying to be true to the algorithm.
> Obviously, the goals should coincide, but focusing on the supplied
> value brings another option t
On Mon, May 11, 2009 at 12:33 PM, lemming110 wrote:
>
> I am trying to use the select keyword in extra. But I cannot properly
> quote the the expression for postrgres. I am using the
> django.contrib.comments. I started with this snippet
> http://www.djangosnippets.org/snippets/1101/ which ret
On Sun, May 17, 2009 at 2:50 AM, Richard Davies
wrote:
>
> Matt Boersma wrote:
>> I think Malcolm implemented this in the Oracle backend rather than Ian
>> K. or myself.
>
> It was Ian Kelly, I think in [10022].
>
>> So I'd say the answer is a).
>
> I
On Fri, Jun 5, 2009 at 1:29 PM, slafs wrote:
> another thing is that I don't understand why NLS_TERRITORY has to be
> set to 'AMERICA'.
Because the region determines how the days of the week are numbered.
I have no idea what mapping POLAND uses, but if it's different from
AMERICA, then expect to
On Fri, Jun 5, 2009 at 2:05 PM, Antoni Aloy wrote:
> I think in your case is quite the same, take a look at
> http://www.oracle.com/technology/tech/globalization/htdocs/nls_lang%20faq.htm
> and the set the enviornment variable NLS_LANG on your application. In
> the setting perhaps.
This won't wor
On Tue, Jul 28, 2009 at 6:20 AM, slafs wrote:
>
> Hi there!
>
> I think I found a little bug in
> http://code.djangoproject.com/browser/django/trunk/django/db/backends/oracle/query.py#L132
> Offsetting the QuerySet (like qs[2:4]) on Oracle backend mixes the
> ordering in the final result set.
> Au
On Sun, May 19, 2013 at 7:33 AM, Shai Berger wrote:
> Hi,
>
> In my quest to solve Oracle bugs, I found the function datetime_cast_sql() in
> the Oracle backend. It causes a problem these days, because it gets in the way
> of querying a date as string (mydate__startswith='2005'). It is a function
On Tue, Jul 30, 2013 at 4:04 PM, Wim Lewis wrote:
>
> On 30 Jul 2013, at 2:06 PM, Florian Apolloner wrote:
>> How do you think such support would look like? For negative indices you'd
>> have to know the size of the resultset to be able to do "limit somthing
>> offset length-your_negative_index"
On Fri, Jun 13, 2014 at 7:40 PM, Shai Berger wrote:
> Hi Tim and all,
>
> On Saturday 14 June 2014 03:52:57 Tim Graham wrote:
>>
>> Release - GA Date - Premier Support Ends - Extended Support Ends
>>
>> 11.1 - Aug 2007 - Aug 2012 - Aug 2015
>> 10.2 - Jul 2005 - Jul 2010 - Jul 2013
>> 10.1 Jan 2004
On Sun, Jun 15, 2014 at 8:59 AM, Michael Manfre wrote:
> I don't see how it should be up to Django to continue to support all of
> these archaic versions of Oracle. To paraphrase the mantra repeated during
> various mssql discussions, "Django doesn't need to include everything in
> core, it just n
On Thu, Jul 24, 2014 at 5:49 PM, Ryan Hiebert wrote:
> My opinion is worth less than 2c, but I’m inclined to agree with the dissent.
>
> It seems to me that its easy enough to install the very latest from the
> github repository versus from a tarball, so leaving RC versions to actually
> be cand
On Fri, Jul 25, 2014 at 7:12 AM, Ryan Hiebert wrote:
>
>> On Jul 25, 2014, at 12:22 AM, Ian Kelly wrote:
>>
>> It seems to me that a new release would be useful to have for the
>> reasons given, but it should be called what it is: a beta version, not
>> an RC
On Wed, Sep 3, 2014 at 10:10 AM, Sam Willis wrote:
> Although I have implemented this with the 'use' word, there may be a better
> word. I considered 'embed' but thought 'use' was a little cleaner
Since it's so similar to 'include', is there a reason not to just add
the new functionality to the e
On 5/18/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
> On 5/4/07, benk <[EMAIL PROTECTED]> wrote:
> ...
> >
> > text length = 3998, saved length = 3998
> > text length = 3999, saved length = 3999
> > text length = 4000, saved length = 4000
> > text length = 4001, saved length = 2001
> > text leng
On 6/1/07, Ian Kelly <[EMAIL PROTECTED]> wrote:
> On 6/1/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > (2) The use of django.db.utils.truncate_name() introduces a
> > small backwards incompatible change for all existing backends.
> >
lly an example of
> usage -- which was why we created the regressiontests/
> directory; to house such non-examples -- but the purposes for
> which the two directories are used has drifted a bit in the last
> year, I suspect.
Will do. I think I'll go
Just wanted to mention that the issues Malcolm brought up here have
since been resolved, and I believe the branch is ready to be merged:
1) Many backends.supports_tablespaces checks: we decided to leave this alone.
2) Backwards incompatibility with truncate_name use: this has been
fixed by leavi
That's great! Thanks for taking the time to work on this. Regarding
(1) below, I suggest that the IPAddressField should have
empty_strings_allowed = False. This will allow Oracle to correctly
handle null values for the field. I will create a ticket for this
some time today.
Thanks,
Ian
On 6/
On 6/23/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Sun, 2007-06-24 at 00:23 +1000, Malcolm Tredinnick wrote:
> > In [5519] I have committed the Oracle branch changes into trunk.
>
> As usual, there's something I forgot...
>
> I flopped around quite a bit when setting up Oracle server
On 6/23/07, Tom Tobin <[EMAIL PROTECTED]> wrote:
>
> Now that boulder-oracle-sprint has been merged into trunk, I'd like to
> ask the Oracle backend developers to take a look at Ticket #1465,
> implementing regular expression field lookups (i.e.,
> "somefield__regex=foo" or "somefield__iregex=foo"
On 6/27/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Hi,
>
> it seems I'm the only one to run the test suite with mysql ;-)
>
> Ticket #4711 - http://code.djangoproject.com/ticket/4711
>
> Currently the tests break because mysql returns 0 or 1 for a BooleanField,
> not False or True. Postgresq
> By the way, for all database backends except SQLite, you can implement
> all of this sort of stuff (including exists and __len__) fairly fast
> using cursor.rowcount (the number of rows in the result set).
> Unfortunately, SQLite always returns -1 for rowcount. I'm building a few
> of those opti
On 8/1/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> - Oracle 10 (check with Boulder guys, but I think that was the minimum).
> The cx_Oracle minimum version is documented in install.txt.
We developed against Oracle 9i and 10g, and so Oracle 9i is sufficient
for the most part. The only fea
Hi, could one of the core devs please take a look at ticket #4827?
This is a severe Oracle-backend bug (syncdb failure) with a simple
patch that's been around since the merge of the Unicode branch. It's
been reported at least four times that I've seen, so I think that
users must be encountering t
On 8/6/07, mamcx <[EMAIL PROTECTED]> wrote:
>
> Ok, I do CD to the folder where test is, then run:
>
> runtests.py --settings test
>
> test.py is a settings file with the new backend and db config.
>
> I do a little debugging and I think find a bug.
>
> The test are executed on:
>
> failures = run
On 8/6/07, mamcx <[EMAIL PROTECTED]> wrote:
>
> Nope...
>
> I change the name and get the same numbers.
>
> The settings must have something special? what is the bare minimun?
This is all that I'm using:
DATABASE_ENGINE = 'sqlite3'
DATABASE_NAME = 'django_test.s3db'
SITE_ID = 1
ROOT_URLCONF = ''
I just tried this, but I seem to be missing the
django.db.backends.introspection module that it imports from.
On 9/14/07, Brantley Harris <[EMAIL PROTECTED]> wrote:
>
> Please review ticket #5461, and the given patch. It refactors the
> creation and introspection modules of all the backends. I
TRUNCATE has transactional side effects, so I'm +1 on adding
model.objects.truncate(), -1 on optimizing
model.objects.all().delete().
Ian
On 9/19/07, Wensing, Matthew (CNI-Palm Beach) <[EMAIL PROTECTED]> wrote:
>
> Maybe there should be a .truncate()? Heh.
>
> Matt
>
>
> -Original Message--
On 9/22/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> Yes, there _could_ be a clash of commands, and a user application
> _could_ override a default Django command. However, I put it to you
> that this is the 1% case, not the 99% case. Most applications won't be
> registering commands, so t
On 9/20/07, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> Oh, yeah. That's Jython's unicode(foo) calling foo.__str__ even when
> hasattr(foo, '__unicode__') under some circumstances.
In case you missed it, Jython 2.2.1rc1 was made available yesterday,
and the changelog includes this line:
- [ 1799
On 10/3/07, Nis Jørgensen <[EMAIL PROTECTED]> wrote:
> While looking through the db-backend settings, I found
> autoindexes_primary_keys. This seems to be True for all other backends
> than mysql and mysql_old.
>
> The only place in the code that this is used is in
> django/core/management/sql.py,
On 10/3/07, Ben Ford <[EMAIL PROTECTED]> wrote:
> Hi guys,
> Thanks for the reply. So if my only recourse at the moment to execute
> qs._get_data() and then work with a slice as a list..? If there's any way
> around that I'd like to hear it, my models are in a legacy DB, and it's
> HUGE!! Is anyon
On 10/3/07, Ben Ford <[EMAIL PROTECTED]> wrote:
> Hi Ian,
> OracleQuerySets currently do not have any slicing ability AFAIK, apart from
> returning a slice of the qs._result_cache list... in the backend refactor
> all of the logic for building the SQL is in a function called
> limit_offset_sql on
On 10/15/07, Carl Karsten <[EMAIL PROTECTED]> wrote:
>
> Who has recently worked on django/db/backends/oracle code? I have some tips
> from the author of the oracle dbapi module. I am not actualy working with
> oracle, so it makes no sense for me to go changing code.
>
> Carl K
>
> >>> 2. you
On 10/17/07, Dan Watson <[EMAIL PROTECTED]> wrote:
> Now suppose you want to build a search engine. Searching for
> Record.name='Dan' would be easy, and searching for Records with a
> RecordValue.value='django' is also [slightly less] easy. But the
> latter requires using a RecordValue queryset, a
On 10/22/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> Hi Matt,
>
> On Mon, 2007-10-22 at 15:04 -0700, [EMAIL PROTECTED] wrote:
> > Author: mboersma
> > Date: 2007-10-22 17:04:00 -0500 (Mon, 22 Oct 2007)
> > New Revision: 6595
> >
> > Modified:
> >django/trunk/tests/regressiontests/for
On Dec 2, 2007 7:31 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, 2007-11-30 at 20:00 -0800, [EMAIL PROTECTED] wrote:
> > To clarify, code such as the following can be a little confusing:
> >
> > p = MyModel.objects.filter(foo__id = self.id).order_by('-timestamp')[:
> > 1]
> > if
On Dec 11, 2007 4:16 AM, Patryk Zawadzki <[EMAIL PROTECTED]> wrote:
>
> 2007/12/11, Malcolm Tredinnick <[EMAIL PROTECTED]>:
> > On Tue, 2007-12-11 at 11:28 +0100, Patryk Zawadzki wrote:
> > > 2007/12/11, Ben Walton <[EMAIL PROTECTED]>:
> > > >
> > > > I was just inspecting a couple of queries my a
On Dec 11, 2007 10:20 AM, Patryk Zawadzki <[EMAIL PROTECTED]> wrote:
>
> 2007/12/11, Ian Kelly <[EMAIL PROTECTED]>:
> > On Dec 11, 2007 4:16 AM, Patryk Zawadzki <[EMAIL PROTECTED]> wrote:
> > > Semantics of COUNT require counting all non-NULL values an
On Tue, Mar 4, 2008 at 10:16 PM, vcc <[EMAIL PROTECTED]> wrote:
> > vcc said the following:
> >> How about: {{ foo.__bar__ }} ?
> >
> > Except you can't use _ as the first character in a template lookup like
> > that,
> > and the __foo__ naming method is already taken by existing things like
On Thu, Mar 6, 2008 at 7:06 PM, Collin Grady <[EMAIL PROTECTED]> wrote:
> To keep things consistent though, you'd then likely have to change normal
> access
> to work like that as well, so instead of foo.bar to look up the key "bar"
> you'd
> have to change it to use foo["bar"], which would b
Sam, please ask Django usage questions on the django-users mailing
list. This list is for discussion of the development of Django
itself.
But to answer your question, it sounds like you're conflating
"tablespace" with "user schema". What you're wanting to do -- have
the Django user be a user ot
On Fri, Apr 25, 2008 at 1:06 PM, AmanKow <[EMAIL PROTECTED]> wrote:
>
> Hmmm... I read the subclassing post. As a non-abstract child is
> essentially a one to one with some syntactical sweetness, I'm still
> not sure how using a one to one field is better suited than
> inheritance for extendi
On Fri, Apr 25, 2008 at 11:40 PM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
> > Have you considered syntax that looks like this instead? :
> > >>> Students.objects.all().aggregate({'average_height': 'height__avg})
> > > {'average_height' : 1.43}
>
> My issue with this syntax is that ev
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
101 - 177 of 177 matches
Mail list logo
