Opened 8 years ago

Closed 8 years ago

#3 closed task (fixed)

Model implementation

Reported by: olivier Owned by: olivier
Priority: major Milestone: Version 0.3
Component: Miscellaneous Version:
Keywords: Cc:

Description

As shown on GlobalArchitecture, the data will be available through a Model layer. The basic idea is:

  • to modelize the main data structures: Collection, MediaItem and Part
  • to completely encapsulate the SQL queries into this model

The choice we made of using the DjangoFramework? may naturally lead us to use Django's Object Relational Mapper. However, we need dynamic properties: an easy way for the administrator to add/remove fields to each of our data structures.

In this regard :

  • we can use helper models to hold these dynamic properties
  • or/and tweak Django models to (sort of) transparently support these properties
  • or we can completely bypass the Django model layer and create our own model implementation from scratch, but still use the rest of Django's features, which appears to be Django compliant

Change History (3)

comment:1 Changed 8 years ago by olivier

  • Status changed from new to assigned

After investigation I chose to implement static models, in the Django way. They allow the mentioned modeling and SQL encapsulation.

Regarding "dynamic properties", the Django models can quite easily be modified to add/remove new fields. This also is a way to drastically reduce complexity, while retaining maximum flexibility. Indeed, chances are high that such dynamic properties would bloat the whole model layer.

We would need powerful properties definitions, with strong types, such as: dates, integers, floats with a given precision, editable enumerations, etc... And there would be many side effects, such as Dublin Core mappings, etc...

In this regard, making a user interface that allows not only adding but rendering such flexible properties brings much more complexity that we can handle currently, in order to reach our milestone, planed for May 20th: milestone:"Web UI & refactoring"

However it shouldn't be that hard for administrators to add new fields to Django models, assuming we properly document this process. Another point that's worth mentioning is that if you make it too easy to add/remove fields (as in Access, FileMaler?, 4D, etc...) it usually ends up with non-technical administrators turning the database structure into a complete mess.

Such badly administered database is not likely to remain usable over the years. It's better to let people with technical skills handle this task.

I leave this ticket open until the model reaches a somehow stable state.

comment:2 Changed 8 years ago by olivier

Regarding the ability to easily add, remove and modify database fields in a Django application which is already installed and running:

The Django team seems to be working on it, they call it Schema Evolution:
http://code.djangoproject.com/wiki/SchemaEvolution

This work even qualified for the Google Summer Of Code 2006:
http://code.google.com/soc/2006/django/appinfo.html?csaid=CE83CE9BB3C461B3

I suppose we might help them in the future, if we have sufficient resources.

comment:3 Changed 8 years ago by olivier

  • Resolution set to fixed
  • Status changed from assigned to closed

As of r104, the model design is clear, and its implementation functional. It tries to follow Django principles as much as possible.

For interoperability and internal use, the to_dom() and to_dublincore() methods are provided, which respectively allow to transform the media objects into their DOM and Dublin Core representations.

However, this is at most beta stage, and shouldn't be considered stable or suitable for production purpose. This is compatible with the experimental nature of milestone:"Version 0.3".

Note: See TracTickets for help on using tickets.