On Sat, 2007-11-03 at 10:58 -0500, Tim Chase wrote: > Using this section of the Master Class notes found here > > http://toys.jacobian.org/presentations/2007/oscon/tutorial/#s103 > > I've been working to create a custom field-type for consolidating > some of my work that was previously duplicated across several > models. The field-type in question is a "PartialDateField" in > which pieces of the date can be missing, or the year can be a > range of years (good for date-of-[birth|death] fields). Thus, my > plan is to have something like > > class Foo(Model): > dob = PartialDateField() > > which then creates "dob_month", "dob_day", "dob_min_year" and > "dob_max_year" fields. Bits and pieces can be absent, so you > might know that a person's birthday month/day, but not the year; > or you might know that the person is between 25-30 years old; or > you might have an exact date, in which case the min/max year are > the same and the month/day fields are populated. > > Since this code is shared across multiple apps in my project, it > seems like it should be put in some file like myproj/fields.py so > it can be shared by myproj/myapp1 and myproj/myapp2 correct?
Makes sense. Or put it into its own subdirectory (python module) if you want to be able to distribute it more easily outside of your project directory. > 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. > 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,1,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. Regards, Malcolm -- A conclusion is the place where you got tired of thinking. http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
