Hi all

One of our projects is a conversion of our old C++ ORM/website to
django (1.4.x). Certain pages/parts of the website have been
redeveloped in to django, and we've provided django models mapping to
the existing tables, whilst other pages are still served from our C++
app.

Some of the tables are look-up tables, with columns like (id,
description). If we were starting from scratch with Django, these
would probably be defined as Model.FOO_CHOICES, with each choice being
defined as Model.CHOICE_ONE. One of our developers thought that this
behaviour should be available even on our old style tables, so they
added a snippet like this in app/models/__init__.py:

  for cls in (ItemType, Category, ....)
      for value in cls.objects.all():
          description = value.description
          key = re.sub("[^\w]+", "_", description).strip("_").upper()
          setattr(cls, key, value.pk)

So, our item type table has this data:

pk    description
1       Item
2       Product
3       Review

and so this snippet adds the attributes to the ItemType class (eg
ItemType.ITEM, ItemType.PRODUCT, ItemType.REVIEW).

This works well in development and production, but because these
statements are at module level in models/__init__.py, we have problems
in testing because the queries are run before the test databases are
configured.

This means that the DATABASES setting for test must point to working,
up to date databases, which in turn means that we can't use in memory
sqlite databases for testing, we must use the same engine and options
as the working DB, and thus (finally!) testing is too slow and has too
many external dependencies.

I can't easily remove the magic - not enough of the code utilising
these attributes is unit tested to find what would break. I can't lazy
load the attributes, as I don't know what the attribute names might
be. I was hoping there might be some signal I could hang this on that
would be fired after either the standard DB connections have been
created, or when the test DB has replaced them, but there does not
seem to be one.

Any ideas?

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFHbX1LJ_o9MkZapep6rd-wWaNqUrnbbsJ7PC%2BLZ0LOd0AqfFg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to