6

Possible Duplicate:
Django dynamic model fields

Good Morning guys! Scenario is the following. For some models on Django, I would like to allow the end user to define his own fields. It would be great if I could keep all Django awesome features like the ORM, so I can still do calls like field__gte to search on the model, still have field validation according to field type, etc. I've thought about two ways of doing this, and I'm more than open for new suggestions. Any feedback would be VERY appreciated.

  1. The first approach, is the Entity-Attribute-Value ( http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model ), which django already has an app for. See http://code.google.com/p/django-custom-field/ I think this would be an OK solution, but I lose the ability to do "mymodel.objects.filter(custom_field_x=something)". Maybe there's a way to regain the ORM, any ideas? But I've heard so many bad stories about this method that I'm little scared to use it.

  2. The second approach would be to have a database table for each of the users (probably no more than a 1000). I've read django has something in the lines of inspectdb, which actually checks which fields are there and produces the model for you. This could be useful but I think maybe I should store the fields this particular user has created and somehow dinamically tell django, hey, we also have this fields in this model. Is this possible? I know it's generally bad to have different tables for each user, but considering this scenario, how would you guys rate this method, would it be ok to have one table for each user?

The model that requires custom fields is for example Person. They might want a custom field to store address, blood type, or any other thing.

MANY THANKS in advance! Have a nice sunday!

Very similar: How to create user defined fields in Django -- but only talks about the EAV, which I would like to avoid. I'm open for new ideas!

Community
  • 1
  • 1
Clash
  • 4,896
  • 11
  • 47
  • 67
  • 1
    Found best reference ever: http://stackoverflow.com/questions/7933596/django-dynamic-model-fields Sorry, my question is a duplicate of that one. Mods, feel free to close it. – Clash Jan 29 '12 at 16:45

2 Answers2

1

One approach is to use a NoSQL document-based solution such as MongoDB which allows you to store objects that have a fluid structure (no such restrictions as pre-defined columns).

Pros:

  1. No restriction on custom field types, number of types of fields, etc.
  2. Retains ORM functionality (django-mongodb)
  3. Other various benefits of NoSQL - which you can read about online
  4. Avoids EAV

Cons:

  1. Need to setup NoSQL server
  2. Additional knowledge required on NoSQL concepts (documents vs. tables)
  3. You may have to maintain two databases - if you decide not to migrate your entire solution to NoSQL (multi-db)

EDIT:

After reading the comments its worth pointing out that depending on which NoSQL solution you go with, you may not need reversion support. CouchDB, for example has built in support for document versioning.

Burhan Khalid
  • 169,990
  • 18
  • 245
  • 284
  • Hi burhan, thanks for your answer! mongodb looks great. Sadly my shared hosting does not support it. I'm now looking for a new webhosting (but that's another matter). Anyways, what I wanted to ask is: do you know if using mongodb breaks any other apps? For example, if I use django-revisions (http://djangopackages.com/packages/p/django-revisions/), will it still work? Many thanks in advance! – Clash Jan 29 '12 at 12:11
  • 1
    @Clash, yes, using mongodb will break external django-apps that don't expect to use a NoSQL db. So django-revisions won't work. However, you could set up multiple databases since Django now supports that. The only issue with that is not being able to join across these databases. – Spike Jan 29 '12 at 16:43
  • @Spike, I see. I wouldn't be able to use revisions on the models that uses custom fields then I guess? Many thanks for you reply! – Clash Jan 29 '12 at 17:59
  • @Clash, correct. Unfortunately, you probably wouldn't be able to use it without making a bunch of changes to it. If you want to use django-revisions and other django apps in conjunction with this app you're talking about, the easiest solution is to stick with a relational db for everything. – Spike Jan 29 '12 at 18:20
  • @Spike, just wanted to say again, many thanks for your advice. It is deeply appreciated. I guess I'm going to stay in the relational land for now. But it was very nice to learn a bit about NoSQL. I look forward to working with it, looks very flexible and straight-forward. – Clash Jan 29 '12 at 18:55
  • @Clash, glad I could help! Good luck with this. – Spike Jan 29 '12 at 19:37
1

what about creating another model for storing user_defined_fields? 

    class UserDefinedField(models.Model):
        #..................
        user = models.ForeignKey(User)
        field_name = models.CharField(max_length=50)
        field_value = models.TextField()

Then you can do UserDefinedField.objects.filter(field_name=some_name,field_value=somevalue)

machaku
  • 1,176
  • 8
  • 7