On 23-8-2012 10:41, geonition wrote: > It is very convenient for me to use GeometryField as I can save any > geometry type into the same field. The database logic will become more > complex if I am required to create a separate table or field for e.g. > points and linestrings. > > Still looking for a workaround, or is there a reason for me not to save all > geometries into the same field?
Well, the reason is that it's kind of like XML. As long as it validates, programs don't complain, but to do anything useful with it you have to understand the structure and capabilities of the specific dialect. And this is exactly what is biting you. As soon as you try to do something useful with it, you need to know exactly what you stored. This applies to the admin but certainly also to queries: What exactly have you stored in relation to the rest of the fields? For a house, you store a point, for a street a line string, for a state/province a polygon - so what exactly is in the table and if you it contains addresses does the geometry field apply to the address/house, to the street or to the province? I don't really understand the fear of using multiple tables, but I do see many problems trying to make sense of your data if a field is polymorphic. The reason you put stuff into a database is to organize things so you can explore relationships between all the bits pieces. That implies you need to cut things up first. -- Melvyn Sopacua -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
