Bill, thanks for answer, my comments are inline:
On Sep 8, 4:29 pm, Bill Freeman <ke1g...@gmail.com> wrote: > Well, do you want this to happen every time that the module is imported? Or > spend time > each server start determining that these items are already in the data base > and skipping > the initialization? If not, then you're stuck telling the system when to do > this anyway (perhaps > a syncdb extension that does them if it has to create the database?). I meant not every time module is imported, only when doing "syncdb" or "evolve" (Django Evolution). So no checks if items are in database are needed, database could be dropped and newly created before this operation. > You do realize that having initializers as default arguments, that they > consume virtual memory > forever, whether the database is already loaded or not. This is good remark. Solution how to avoid that could be to have somewhere (maybe in settings) flag, for example LOAD_SAMPLE_DATA=True/ False, and these data would be loaded only when set. Or running syncdb or evolve could temporarily set this flag to true. > That isn't > significant for loading 3 rows, > as in your example, but I presume that you're actually loading a much larger > set. Larger, but not much. Approximately 0 - 30 items in various classes/ tables. > I typically have a CSV file, or a pickle of a list of dictionaries, and use > csv.DictReader or cpickle.load > in a loop that creates a model instance, populates such fields as have keys > in the source, and saves > the instance. I think that it's less work than figuring out how to > configure some extension, and if you > let it be driven by the keys present, the code is pretty generic (at least > for the pickle; with the CSB > you typically want to convert some strings to ints, floats, and bools. You > can also use XML, but I find > it more complicated, though attributes could control conversions.) > > I've taken to putting that code in a separate load.py file, so that even the > code isn't loaded in the > server. You could also just hand code a list of dictionaries in such a > file. I still wind up running the > code from the manage shell, though you could certainly create, for example, > a view that imports the > load.py only if the view is referenced (by someone with enough privelege), > and runs the code. Or > you could figure out how to attach it to syncdb. > > But you should probably look at fixtures. I haven't, as yet, but should. > They seem to be a supported > means of initializing a database. In my previous projects (not in Django), it was common practise to load some data in CSV or XML. Django fixtures - I used them several times, but I see it only as alternative of CSV or XML. Disadvantage of these traditional approaches is, that data are maintained separately from code. When the code evolves (e.g. renaming attributes, moving attributes between classes or packages, ...), the same changes need to be done in files with sample data, and it seems tedious to me. I know, that I cannot avoid traditional approach, when e.g. migrating production data from one version of application to another version, it is unthinkable to put production data in the code ;). But when developing application (currently my case), there is only relatively small set of sample testing data, and I see as big avantage and developer's comfort, to be able modify sample data accordingly with code modification. If such functionality would become part of Django, or Django Evolution, I'd be happy. Jano > > Bill > > On Mon, Sep 7, 2009 at 4:43 AM, Jan Ostrochovsky <jan.ostrochov...@gmail.com > > > wrote: > > > Thanks Bill, yes, that is one possible solution, when implementing > > such feature from the scratch. > > > I am only asking, if there is some existing framework for such need, > > which I see as common. > > > For example some add-on to Django, which will do this for me. Let's > > imagine additional option for any field of Django model, e.g.: > > > class Person(models.Model): > > firstname = models.CharField(max_length=30, initial_values="John, > > Bill, Peter") > > lastname = models.CharField(max_length=70, initial_values="Smith, > > Clinton, Parker") > > ... > > > Django with such add-on could be able to build initial database from > > these values, for example when running syncdb or other way. > > > Am I more readable now? > > > Jano > > > On Aug 20, 10:09 pm, Bill Freeman <ke1g...@gmail.com> wrote: > > > Perhaps I'm not understanding correctly, but how about, assuming you have > > a > > > function > > > run_data_inits() that calls your chain of init_sample_data() functions: > > > > $ python manage.py shell > > > > >>> import myproject.myapp.models as m > > > >>> m.run_data_inits() > > > >>> ^D > > > > Bill > > > > On Thu, Aug 20, 2009 at 9:25 AM, Jan Ostrochovsky < > > > > jan.ostrochov...@gmail.com> wrote: > > > > > Hello, > > > > > we are in the initial phase of software project, and data model and > > > > names of attributes are changing very often, and very often we need to > > > > create new database and fill it with the same sample data for testing. > > > > We want to automate this creation of sample data. > > > > > Our idea: add into each models.py method e.g. init_sample_data() to > > > > each model class, and put sample data there (with well handled > > > > dependencies - ForeignKey, etc.) and each time we change model, we > > > > will aslo change concerned init_samle_data(). We will run these > > > > chained init_sample_data() for each class in the script. > > > > > The question is: is there some existing solution for this (in Django > > > > or its extensions), which we can use, and not reinvent it, or not? Any > > > > idea? > > > > > (We are using Django Evolution, which is good help, but only when > > > > changes are not too dramatic.) > > > > > Thanks in advance. > > > > > Jan Ostrochovsky --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
