Re: Database pooling vs. persistent connections

/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 e

Re: Django and the Eyjafjallajökull eruption

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

Re: Problem with history view in admin page

> > 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

Re: Problem with history view in admin page

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

Re: Oracle backend TextField unique=True error

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 -

Re: Oracle backend TextField unique=True error

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.

Re: Oracle backend TextField unique=True error

> 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

Re: Problem with history view in admin page

> 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.

Re: Problem with history view in admin page

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

Re: Problem with history view in admin page

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'

Re: Problem with history view in admin page

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

Re: Problem with history view in admin page

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

Re: Problem with history view in admin page

>> 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

Re: Public spec is needed for writing ORM adapters

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