/eab320359f0d16d8?hl=en_US)... , so i
am curious how the above approach deals with the multi-threaded
scenario
regards
Mario Briggs
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emai
>>
On May 23, 3:07 am, Anssi Kääriäinen wrote:
> On May 23, 12:35 am, "Daniel Sokolowski"
If there is need and interest for similar work for DB2 I am
> willing to commit patches...
>
Anssi, thank you very much for the offer. We (IBM_DB_DJANGO team) will
certainly reach out to you if we are in ne
Hi Helgi,
that's an awesome story. We share your appreciation.
Rahul and Ambrish would be really satisfied and motivated if their
ibm_db_django adapter was used in this.
thanks
Mario
On Jul 2, 4:03 pm, Helgi Borg wrote:
> Remember the Eyjafjallajökull eruption that stopped air traffic over
> p
>
> I'm not sure what you're asking me. "Blockers" of what?
>
I meant, for sure we know that the backend can switch the lookup to
the hidden column (from the original column) by overriding -
'field_cast_sql(self, db_type):'
The backend also needs to execute the SQL to create the hidden column
du
Russ,
The indexing that Oracle is supporting is 'index-on-expression'. DB2
also supports that, but it isnt enabled for character long columns,
since they hadnt had a request for that. I talked to the DB2 server
folks about these use-cases and they have agreed to support this via
index-on-expressio
thanks Peter for the use-case writeup. Not having to overrun the max
length seems to make the choice for text for most folks.
I had a look at the indexing capabilities of a some db's on text. I
couldnt find Postgres documenting limits but according to this its
2713 -
http://joseph.randomnetworks.c
Hi Ian,
Ian Kelly wrote:
> Not currently, no. And if I were to put in some work on improving on
> the Oracle backend's support for filtering on TextFields, I would
> concentrate first on fixing the query so that it correctly compares
> the entire TextField and not just the first 4000 characters.
> This is known. The Oracle notes [1] mention that TextFields cannot be
> indexed. Since Oracle requires indexes for unique columns, this also
> means they cannot be unique, although we should probably make that
> explicit. It may also be worthwhile to check for this when the models
> are valida
> The *only* reason that we are even talking about adding this field is
> because DB2 can't index on the datatype that is the natural match for
> a length-unlimited TextField.
> Oracle's indexing imposes an
> implicit limit of 4000 characters; that sounds to me like as good a
> number as any.
Rus
I was too harsh on the GenericKeyField. How about GenericKeyField
(length=x). I think the reason i put length in there is obvious, but i
can explain if need be.
In post #14 on this thread you suggested - " I'm not wild about the
idea of having underlying datatypes change based on attributes in a
f
Russ,
I dont agree to the *it works* theory here - Ian rightly said 'If you
ask me,
anybody foolish enough to use a TextField as a primary key deserves
what they get' and you agreed 'Your comment about foolishness is
definitely correct '
Putting it in context, this is in the 'user control area'
Richard,
> I don't know why a user should have .filter(object_id='1')
> fail, as that breaks the ORM abstraction. Maybe that's not what you're
> suggesting?
I am saying exactly what i am saying. So here's my example that does
the same thing in a java ORM
// Here's the model
@Entity
public class
Russell,
> >> Well, Django doesn't make the decision to use CLOB - that's in the
> >> hands of your backend. In the same circumstances, SQLite and Postgres
> >> use 'text'. MySQL uses 'longtext'. Oracle uses 'NCLOB'
I understand that the decision to what 'Text' should be mapped to is
the choice o
>>
What is stored in this field is a string-serialized representation of
the
primary key value.
<<
I agree that INTEGER is not the right choice, but then so too is CLOB.
How long is this string-serialized representation going to be? greater
than 4000 characters ? Varchar(X) where X is > 4000 or s
We are still interested in providing the adaptor. Look forward to the
'Getting Started'.
Regarding the 'Maintaining problem', this is not a problem as
evidenced by the IBM Rails adaptor project as Rails has progressed
from 1.x to 2.x
On Apr 14, 2:26 pm, Robert <[EMAIL PROTECTED]> wrote:
> If have
15 matches
Mail list logo
