On Fri, Jul 4, 2008 at 12:27 AM, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> So the new [...]
A quick update: After more testing with real django applications I
discovered that I was breaking get_next_by_FIELD. This fourth patch[1]
fixes this issue and includes tests for this use case (which wasn't
On Thu, Jul 3, 2008 at 10:36 PM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
> I've also read through the patch already and it seems like the right
> track. I like the approach, since it helps in a few areas, including
> field extensions and extra database backends.
>
> I haven't given it a
On Thu, 2008-07-03 at 16:57 -0400, Leo Soto M. wrote:
> Hi all!,
>
> I've posted a patch[1] with a small refactor to some Field's
> get_db_prep_* methods. Basically, for non-basic field types, the
> database-prepared values is not computed by the Fields anymore, but
> delegated to
On Thu, Jul 3, 2008 at 8:27 PM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
>
> On Fri, Jul 4, 2008 at 4:57 AM, Leo Soto M. <[EMAIL PROTECTED]> wrote:
>>
>> Hi all!,
>>
>> I've posted a patch[1] with a small refactor to some Field's
>> get_db_prep_* methods. Basically, for non-basic field
On Fri, Jul 4, 2008 at 4:57 AM, Leo Soto M. <[EMAIL PROTECTED]> wrote:
>
> Hi all!,
>
> I've posted a patch[1] with a small refactor to some Field's
> get_db_prep_* methods. Basically, for non-basic field types, the
> database-prepared values is not computed by the Fields anymore, but
Hi Leo,
Hi all!,
I've posted a patch[1] with a small refactor to some Field's
get_db_prep_* methods. Basically, for non-basic field types, the
database-prepared values is not computed by the Fields anymore, but
delegated to DatabaseOperations functions. As the current default
logic was copied to the
