On Tue, Mar 11, 2014 at 11:42 PM, RLange <lange.richar...@gmail.com> wrote:
> I'm currently working on an app for browsing and visualizing time-series > data. Each point of time-series data may be a mix of Strings, Floats, and > Ints. In my current design, I have a separate model for each of my data > types, and I have been writing a new view for each one. In other words, my > app is strongly coupled to the structure of the models. *Ideally*, my app > would use some sort of generic abstraction of a time-series model such that > adding new types of data is a simple settings.py configuration, and the > views for browse/visualize would be free. > > I see a few possible avenues to accomplish this. None seems clearly better > than any other. My database is MySQL. Any feedback is helpful! > > 1. Use django-mutant (or equivalent) to make new models on the fly. > However I would really only need to make models at initialization time, not > at runtime. > 2. Instead of a column for each dimension of the data, use a Blob or > Text type for headers and one for data (a hack for variable-length data. > makes intelligent queries nearly impossible) > 3. Forget about pluggability and continue developing under the > assumption that this app will never leave "in-house" > > > This is a deliberately vague question since it is about a vague topic: > abstraction. I can provide more details about my specific use case, but > that seems to defeat the purpose of writing a generic app. > There's actually a fourth option - Continue to write project specific models, but make the visualisation layer generic. This is what Django's admin does. The admin is able to build a generic administration interface for *any* model, given nothing more than the name of the model. If you provide some additional configuration (like which columns you think are important), it can improve that visualisation. Admin does this by using Django's introspection capabilities. Every Django model knows what it is called, what fields it has, what relations it has with other models, and so on. This information is all contained in the _meta attribute of every class or instance. ModelForms use the same capability to determine how to display a form for any model. Back to your example: I imagine you would build a time-series model, and then register it with your visualizer. The visualizer might need to be told details like which field is the "time", and what units that time is in. But from there, it should be possible to find all the "data" columns on the model (or, again, discover them by introspection), and generate a visualisation for them. A very bare-bones implementation of what you're looking for can be found in Django's databrowse app. Once upon a time, this was shipped as part of Django's contrib packages, but as of Django 1.4 it was split out into a standalone package, and is now being independently maintained: https://github.com/Alir3z4/django-databrowse I hope this helps! Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAJxq84_pJg1CYbJY2KDO787qvoOUJtRvnmq1mnfLNYg50UW7_A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
