What is the best way to have model fields translated in Django? I've thought about adding extra fields to the model (one field per language) or creating another model with all texts in every language, is there a recommended way to achieve that?
Thank you very much
NB : I first voted to close this as primarily opinion based but then it struck me that there were actually technical reasons to choose one solution or the other...
Both approach are valid and as a matter of fact you'll find reusable django apps based on either one of the other.
Technically, there are pros and cons to each design.
Using distinct "translation" objects means you'll have an additional join or query (to get both the "master" model and it's translation(s)), but you have no overhead on the master model itself (without translation). Also, it makes create/update operations more complicated.
Using additional "hidden" per-language fields avoids the join / additional query overhead and keeps create/update operation simple, but makes records much bigger so it has some overhead wrt/ the database itself (page cache management etc) and the volume of data going back and forth between your django process and the database.
As a general rule, if you have to support a lot of languages and/or have to translate a lot of text fields for each model, you'll probably want to use a distinct model for translations, while if you have few languages and only a couple "translatable" fields per model the "hidden field" approach will be simpler to implement and will avoid the extra queries / joins.
As far as I'm concerned, I've had experience with both solutions and found the "hidden field" solution (using django-modeltranslations) to work fine for our current needs (four languages supported and we should not get much more, no more than =~ four translatable fields per model, and those models are rarely updated so we can cache aggressively if needed), but you may have totally different needs.
In all cases, don't even try implementing this from scratch, use one of the existing django apps instead, it will save you a lot of time and pain.
Check out their docs django translation
This will help too
Localization: How to Create Language Files - Python Django Tutorials
Related
I'm new to web development and databases (I am currently using Django and PostgreSQL) and I have a general question about databases, because other than the fact that they store data, I pretty much know nothing about them.
I was wondering if it's good practice to have as few fields as possible in my models?
For instance, I have a Model that has a DateTimeField() and was considering also creating a CharField() that corresponds to the month that the instance is related to (I won't delve into details). The consideration of adding this month field sparked me to ask this question.
I clearly don't need the month field because I could parse it out of the DateTimeField(), but it's more convenient to just have a string with the month name rather than parse it. Is it acceptable to add another field for convenience or should I have as few fields as possible?
Really not very pleasant to have to much field, but if a field is month like that, you can use computed field. I don't know if that exists in Django. If not, just use a view to show that month. You will get trouble when updating that and forgot to update one of the field holding same information.
My experience: if database is stored on fast hard disk, best much more fields, because you save time to write code and cpu resources of machine where is the client of database; instead of databse is on old or not fast machine, is better that the client make the job.
Same if the connection from client and server is slow.
What you want to do is called Database Denormalization. By doing that you can optimize the read performance of the table, but you also have to take responsibility that any redundant copies are kept consistent.
So do you really have such performance drawback? (I doub it but..) If you really have, what you can do before adding redundant columns is to try adding column indexes.
I'm new to Django and web frameworks in general, but have worked with DBMSs quite often. Knowing that each class within django models maps to a table in the database, should the models be based on an ERD where tables are normalized? Would normal form matter in this case? Thanks!
Assuming you're using a SQL backend (i.e. not something like mongodb), then the same guidelines for normalisation would apply. Remember, django is just a pretty way to access the database, but in the backgroud you're still executing a series of sql queries which will benefit in the same way from normalisation.
That said, a lot of the business logic that you would normally build into the database can now be handled by django, so it is possible to get away with a slightly de-normalised structure if it makes working with it easier. The approach I usually take is to normalise where it makes sense to avoid duplication, and de-normalise where a normalised structure would result in really complicated queries (django doesn't like complicated queries). I ensure consistency in the data though the use of receivers or overloading the save method.
So I implemented Haystack with ElasticSearch a week ago within our BETA application. One thing I can notice is that getting some data (large amount) back to our users (for example listing all the users within the application) is much faster by going through Haystack then Django's ORM. Now, I will be releasing a REST service (with TastyPie) to serve the possible tablets within the next weeks, as I want to be able to access the information from iPads, Nexus tablets and so on.
One thing I was wondering, is when should I be querying the ORM vs Haystack/ElasticSearch? For example, if the user on the tablet is requesting a specific set of users, should we let TastyPie query the ORM, or go to ElasticSearch?
If we look at this answer Django: Haystack or ORM, we can all agree that a DB is made to retrieve and write data. However, could we say that retrieving faster can be faster with Haystack/ElasticSearch once the search engine was updated?
I am a bit confused as to when, should we not be querying Haystack if it is much faster?!
To make things clear I guess you're talking about querying Elasticsearch via Haystack without later instantiating any objects for your search results with data from you database.
Some points to consider besides the points mentioned in the other post:
A search engine like Elasticsearch is highly optimized when dealing with full-text searches (When doing something with SQL it highly depends on the database/engine you are using)
Queries that are involving a lot of relations/joins will most like be easier to handle with the ORM, but on the other hand you can eg save data from foreign-key relations in a denormalized fashion when using ES which could give you a performance boost. Of course you can denormalize your database tables as well but this is quite often considered as a bad practice as long as you know what you are doing, eg when solving a performance bottleneck.
ES is somehow quite easy to scale while scaling your SQL DB might be more complicated.
Most likely this is a decision that depends very much on your use case, the amount of data to process and the queries you are intending to run. So the best thing of course is - as always - to do some benchmarking yourself and compare this two solutions. But don't do any premature optimisations as one big advantage of the ORM is to keep things simple - you don't have to care much about the integrity of your data and maintain an additional system.
I am working on a Google App Engine application and I am relatively new at this.
I have built an app already in Django and have a model using a field type of ManyToMany.
I am aware that django-nonrel does not support many-to-many field types of Django. So I am considering using ListField instead.
Questions:
- What is the implication of using ListField instead of ManyToMany?
- I am aware that this means that Django's JOIN API cannot be used. But what does this mean for my app?
- Am I going to have problems when it comes to doing a search for something in a many-to-many field?
Apologies if these are programming 101 questions. I'm a designer trying to get my head around development.
Thanks
Well as you probably know, you will be spanning the relationship more manually.
Django cannot help quite as much as when using ManyToMany, but it should not be that big a problem.
Depending on the complexity of the relationship, you might want to consider building a model just for this purpose.
I have never used that approach on GAE, since IMO its only valid when an object has alot relations (more than 50 I would say) or when the lookups you plan to do, will benefit from this. Maybe because they start at either end of the relationship with equal frequency or it would be nice to be able to loop over the relationships to display them or something along those lines.
Last time I made something on GAE I used the ListField (or ListProperty as it was known then) since most of the objects only had about 20 related objects and the lookups would rarely go the other way.
So all in all, its not a big deal and I don't remember it as any kind of a pain to work with/around.
Hope this was helpful despite it being rather "IMO"
I'm trying to solve the relational model in order to make a Django app.
I't will be something like a McDonald's crew scheduler. I mean the grid with colored pins marking who will be working at a given hour a given weekday.
I did try to Google out some example, but I didn't find anything. I need some theory/bibliography in order to build up my model and code it into my app.
Thanks in advance
From the short description, you probably wouldn't have just one model in your app.
From your question I'm assuming you don't have a lot of experience with databases... Here are a few suggestions:
Start here because if you don't understand the basic principles of database design, foreign keys, one-to-one, one-to-many, many-to-many, etc etc etc; you will have a hard time designing your Django models.
It would be nice to learn SQL too. Django models are supposed to insulate you from it, but in reality it is using SQL underneath and knowing SQL will enable you to check and fix performance issues in the future. There are some resources online too. And if you are using SQLite, learn its syntax too.
The above is stuff that you will be able to reuse regardless of the web framework you end up with. Django, Rails, the next big thing... whatever.
Study other people's data models. Here are several different ones - maybe you can find the one you are looking for (employee shifts? shift scheduling?).
Then read the basic django model documentation and really understand it. What django models are doing is mapping python objects to relational database tables (ORM is the acronym; Object Relational Mapping) and this article may very well help you in coming up with good designs.
Don't get discouraged. Everybody had to start somewhere.
Hope you find all you need. Have fun with Django.