This question already has answers here:
Closed 11 years ago.
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.
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.
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!
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:
No restriction on custom field types, number of types of fields, etc.
Retains ORM functionality (django-mongodb)
Other various benefits of NoSQL - which you can read about online
Avoids EAV
Cons:
Need to setup NoSQL server
Additional knowledge required on NoSQL concepts (documents vs. tables)
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.
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)
Related
In a Django application, I have three models:
Service
Product
AppliedTax
I want to create a many-to-many relationship between Service and AppliedTax and between Product and AppliedTax. Normally I would have an intermediate model (i.e. AppliedTaxTaxable) with three fields (applied_tax_id, taxable_type and taxable_id) and taxable_type + taxable_id would be a composite foreign key for each related model with taxable_type having as value the name of the related model (Service or Product in my case) and the taxable_id field the id of the related record of the respective model.
I understand how to make it work with raw queries, but Is there a "Django" way to do that with a ManyToMany relationship? So far I had no luck with that. I don't have much experience with Django, but I hope there is a way to do that without using raw queries.
Help :)
Well, after some thought, I did a better search and stumbled upon django-polymorphic. Here is a pretty straightforward explanation on how it works, for a basic set up and it does what I am describing in my question. The implemented schema differs a bit from what my description, but in the end we will home one intermediate table for all associated models.
Anyone can suggest me any good solution? The problem:
There is spreadsheets with data and i need to create a model with more than 40 of indexable fields (maybe even more in future) is there anything to help me to avoid hand work to define this fields manually? The fields are some kind of chemical parameters with long names, i guess need to create aliases to access them easily.
UPD: googled for a hour, can't find anything. Maybe i'll just create model dynamically from configuration stored in YAML or JSON file? Or use Postgres JSON field? But i feel it's gonna be disaster to make admin interface to work with it.
Well, after the accurate research of the subject i found few options:
Store main part of parameter in Postgres as a columns and the rest in mongodb and use proxy model/custom manager to retrieve this data when required.
Postgres HSTORE (but only for string fields) https://docs.djangoproject.com/en/1.9/ref/contrib/postgres/fields/#querying-hstorefield
And Entity Attribute Value Model https://en.wikipedia.org/wiki/Entity–attribute–value_model
Dynamically creating models from JSON/YAML configuration.
I am currently working to write a web app where people fill out the necessary information, and apply to their mentors.
So, at this point, mentors have a model class that is pretty much like the applicant's, so that they can correct the applicant's info without affecting the applicant's original profile.
I will appreciate any helpful comments. Specifically, I am looking for:
-A similar per-exisiting django app that does more or less so I can browse the source.
-Any special Django feature that allows this that I can not aware of.
-General info on how things like these are done in general.
Thank you.
Ad general info)
You would benefit from doing this in a single model (say ApplicationModel), with fields in pairs - field_name_applicant, field_name_mentor.
Then use a CreateView with its fields property set to only the *_applicant fields for the applicant to fill in the applications initially, and an UpdateView with its fields set to the *_mentor fields for the mentor to correct the applicant fields.
Have ApplicationModel.clean() copy all *_applicant field values to their *_mentor counterpart if the later is not set.
Now you have all your business logic in the model where it belongs; quoting a headline in the introduction of Two Scoops of Django:
Fat Models, Helper Modules, Thin Views, Stupid Templates
I'm building a web-site for a social interaction on a particular topic, based on threads, think of gmail, only public. There will also be some static info in vocabularies, as well as blog, how-tos, knowledge base, etc. It is django+postgres.
One of the most important requirements is a full-text search over all information, regardless of the type of a model. If the exact search phrase appears in the blog, and its twisted sister in messages, than a snippet from the blog entry should appear first in the search results and be followed by a snippet from the message. So, i need a table with all the texts indexed, and the links to _any_other_table_ in the db.
My first idea is to create a separate model with "loose reference", e.g.:
class Content(models.Model):
obj_id= CharField() # An id of the object of a given model.
model= CharField(choices=("Message", "BlogEntry", "HowTo", "EntityProfile",))
content_type= CharField(choices=("subject", "body", "description", "tags",))
body= TextField()
But it feels kind of wrong... This promises an unnecessary hassle around integrity of references when creating and re-linking instances.
So, the question is - is there any elegant solution that django would provide? What might be the most efficient architecture to solve the problem?
I am not asking for a direct answer, but rather a hint.
Thanks in advance!
I've had a lot of success working with this snippet, which uses PostgreSQL's tsearch2. I've tweaked it for various different purposes in various different ways, but basically it works very well, and is very easy to implement.
Thanks a lot for the hints!
while contenttypes is an ideal for this kind of task, it is really tempting to be DB independent
from what i've read so far, Solr is a reliable search engine, but i think, i'll go and try ElasticSearch via Haystack
thanks again!
I've worked on multiple sites recently with similar content types but haven't gotten the design I'm looking to achieve.
I have multiple types of content article, interview, video, gallery, blog, etc. All of these models have very similar properties (title, slug, body, pub_date, etc). And since I'm using django and the admin, almost all the admin setting are identical as well. Most will only have one or two additional fields (ie. filename for video, author for blog).
Currents options are
Using single model "Post/Article" and then just have a type_of_content field. This gives me a single model which makes searches easier and faster and its easy to maintain one model. Managers could be used to pull certain types of content.
Have models 'Video, Interview, Audio' subclass a model called "Post/Article". Gains flexibility of working with different models without all the redundacy. Lots of joins though and all the admin code is still duplicated.
Be very redundant and create a separate model for each type of content even though they share the majority of fields. More stuff to maintain, not DRY at all but highest level of flexibility.
Any insight from someone with more experience would be great.
Thank you.
I don't have that much experience with Django, but it sounds like what you want to do is subclass off of an Abstract Base Class. This avoids creating a table for the abstract parent class, so you get the advantage of your option #2 without the need for joins.