2009-12-09 3 views
1

В настоящее время я работаю над проектом по реализации интерфейса Django для существующего приложения календаря. Приложение календаря имеет MySQL как БД.Django & customizing устаревшая база данных

В нашем пользовательском приложении мы хотели бы изменить/расширить данные в одной из таблиц, используемых существующим приложением календаря, например.

# Auto-generated by inspectdb - table used by calendar application 
class CalendarEvent(models.Model:) 
    name  = models.CharField(max_length=80) 
    start_time = models.DateTimeField() 
    end_time = models.DateTimeField() 


# Manually created table 
class CustomCalendarEvent(models.Model:) 
    code  = models.CharField(max_length=80) # Mapped from name 
    length  = models.DateTimeField()   # start_time - stop_time 
    .... additional data .... 

Мы также хотели бы наше представление данных, чтобы оставаться в синхронизации с существующей таблицы календаря т.е. когда новые записи сделаны в приложении календаря они будут автоматически распространяться на нашей пользовательской таблицы.

Я могу придумать пару очевидных способов сделать это (например, скрипт синхронизации, инициированный cron или, возможно, триггеры MySQL), но я не чувствую, что эти решения являются особенно элегантными.

Одна из возможностей состоит в использовании Custom Manager для CustomCalendarEvent и переопределить get_query_set функциональные возможности также вызвать функцию синхронизации.

Это законное использование пользовательских менеджеров Django? Если никто не может рекомендовать альтернативный подход к этой проблеме?

ответ

2

Похоже, вы пытаетесь расширить CalendarEvent с большим количеством полей.

Во-первых, я хотел бы сделать это изменение CustomCalendarEvent:

code = models.CharField(max_length=80) # Mapped from name

calendar_event = models.ForeignKey(CalendarEvent)

и если длина только вычисления разницы в днях между start_time и END_TIME Я хотел бы удалить его из CustomCalendarEvent и сделать его вызываемым в CalendarEvent (просто метод, который выполняет вычисление).

Вы действительно не хотите дублировать данные между двумя таблицами - это то, что вы получаете, когда у вас есть name в CalendarEvent и code в CustomCalendarEvent. Обновления имени должны быть синхронизированы с code, и нет причин для этого, если все, что вы хотите сделать, - это расширить таблицу CalendarEvent с большим количеством полей.

Затем you could override the save() and delete() methods для CalendarEvent для распространения изменений вставки/удаления. Обновления, я считаю, не имеют значения в вашем случае, поскольку CustomCalendarEvent является просто расширением CalendarEvent.

Альтернативный подход: используйте триггер вставки в базу данных CalendarEvent, который распространяет запись в CustomCalendarEvent. Я бы по-прежнему имел таблицу CustomCalendarEvent, имея внешний ключ в CalendarEvent вместо дублирования данных.


EDIT: Кстати, я никогда не использую бы, custom manager модифицировать данные, как вы предлагаете, даже как побочный эффект некоторых операции чтения. Менеджеры спрашивают, а не об изменении данных.

+0

Спасибо за ответ.Началось чувство, что я злоупотребляю целью Custom Manager. – Martin

2

Почему вы не используете наследование модели? CustomCalendarEvent может наследовать от CalendarEvent и добавлять новые поля таким образом.

+0

Это тоже очень хорошая идея. См. Http://docs.djangoproject.com/en/dev/topics/db/models/#model-inheritance – cethegeek

+0

Да ... это хорошая идея. Я знал, что Django поддерживает наследование абстрактным суперклассом, но не понял, что могу просто расширить существующие классы, что в этом случае мне не разрешено изменять. – Martin

Смежные вопросы