Malcolm,
Thanks for taking the time to look into my questions.
>> I'd like to build some automated tests as I go along, but I'm not
>> sure how to go about building a test harness that creates a
>> temporary model with my field-type, creates a table in the DB
>> with that field in it, and then performs operations on that table.
>>
>> I know how to go about dynamically creating a model, but then I
>> need to syncdb on that model, test it, and then drop/truncate the
>> test table.
>
> This smells a bit over-engineered. Have a look at how the standard
> Django tests work (tests/modeltests/*/models.py). Create a model in your
> test file (models.py) and then write docstring test that play with it.
> Or create the model and then write unittests that work with it. Don't
> try to create the model dynamically, because then you're trying to test
> both your own code and your understanding of Django's undocumented and
> not necessarily stable dynamic model creation process.
Thanks for the tip. It's almost as though any tests for a new
field-type are a stand-alone project/app, as the functionality of
the new Field stands alone from any actual other code in the
project. Your idea of putting it in its own subdirectory is a
mere hop away from being in a standalone testable app. The
testing app can merely have a model that has such a field in it,
and then exercises that field with doctests/unit
A little conditional code in my settings.py can include this app
in my INSTALLED_APPS while testing, and omit it in a production
version (much as I do for serving my static media from the
development server, but letting Apache handle static media in
production). I know it's generally bad form to change
configuration settings between testing/development/production,
but such isolated changes make appropriate functionality
available when needed and remove it when a proven solution works.
>> I'd also like to be able to do comparisons of these
>> PartialDateFields on the DB side of things, having them
>> translated to their appropriate corresponding code (for the __lt,
>> __gt, __between, __range, etc bits). Thus, it would be nice to
>> be able to write code like
>>
>> foos = Foo.objects.filter(dob__gt = date(1955,4,1))
>
> I'm not entirely sure what you mean here, since you give your preferred
> syntax without describing what it does. So guessing a bit...
>
> As part of constructing the query, the get_db_prep_lookup() method on
> each Field class is called to convert the value you give into the right
> format for SQL. Have a look at how that works in
> django/db/models/fields/__init__.py (there's a default Field version and
> some subclasses override it).
>
> What you cannot do easily is convert something like dob__gt into
> *multiple* pieces of SQL. In the future (after queryset-refactor is
> merged) you will be able to write something that looks like a Q object
> and has access to the full SQL query for making additions like that, but
> it will still require writing a bit of code yourself (this is a far, far
> edge case, after all). Not impossible, though.
Yes, you've divined my intent despite my opaque one-liner. Since
the "dob" field is actually comprised of the four parts (month,
day, min_year, max_year), the above would unpack to something like
WHERE dob_max_year > 1955 OR
(dob_max_year = 1955 AND
(dob_month > 4 OR
(dob_month = 4 AND dob_day > 1)
)
)
with the __lt variant using dob_min_year instead of max_year.
Fortunately, SQL is a bit smarter about null-comparisons than
Python so the above should work regardless of null column-data
(as you need progressively more detailed information in that
particular order).
I've looked over the get_db_prep_lookup() as well as the
promising-sounding get_where_clause() in db.models.query but
neither looks like what I want to be able to do.
I may go the route of a custom set of managers, but was hoping to
avoid doing something on a per-model basis, and instead have the
field smart enough to know how to mung its own SQL. If I'm
feeling really daring, might it make sense to refactor some of
this functionality into the Field class to allow for it to be
overridden by subclasses just such as this? Currently the
get_where_clause() is simply a module-level function that seems
to only be called from one place in that query.py file, and only
used where there's already a subclass of the Field in context.
I've "svn up"'ed my trunk code and will try my hand at a hack
this weekend.
Given the threats (and the eventual blessing) of the
queryset-refactor, it might be just a temporary stop-gap.
Thanks again,
-tim
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
