On Sat, Apr 13, 2013 at 12:25 PM, Joey Espinosa <jlouis.espin...@gmail.com> wrote: > Thanks, Tom. I'm familiar with fixtures. My problem is that I don't know > which fields exactly will be date fields (so I have to check each model for > those fields), and then increment them according to the current date (which > will change every day).
I don't understand this - are your models dynamic? Surely you know which models have date fields, you know what objects you want to create with your fixtures. > > So if a demo happens on the 9th, and my field is set to the 15th, then > tomorrow when I reset the data that field must be set to the 16th (because > the date would now be the 10th). Then on the next day, after the data has > been reset, that field would need to change to be the 17th (because the > current date would be the 11th). Similarly, I'd have to do the same with > every other date in the database, without knowing exactly which fields I > have to change (I only know which "type" of field needs to change), and > without knowing when exactly the database needs to be reset (could be twice > a day, once a day, etc... I can't assume the current date will be different > every time this reset happens). Each time you want to reset the data for a demo, you clear the database. You then reload your fixtures. Because any object with a date is loaded from a SQL fixture, with the date being relative to todays date, the dates will be correct for the next demo. You've just got to go through your fixtures, work out which models - and particular instances of those models - want to have dynamic dates, and migrate those objects to an SQL fixture. I suppose if you have a lot of date fields/instance that could be a lot of work.. > > That's my issue in a nutshell. I will have an initial fixture for the data, > and I'll probably have to store the date the initial fixture (the baseline) > was created. That would give me the appropriate date from which to take a > "delta" (i.e., this field is +5 days, this other field is -41 days, etc). > Then, when the data is reset back to that fixture, I'd have to go through > all the data and find any date, and adjust it to the current date (whatever > that may be) according to that field's "delta" (i.e., +5 days from today, > -41 days from today, etc). > > This way the "state" of every object in the database remains the same as it > is on any other day, because the ONLY variable that ever changes in a > database dump is its relationship to the current date (time always changes). > I need to keep that consistency to ensure that demos with potential clients > always follow the exact same "pitch" (otherwise there may be an expired > object over here, a process that may have already happened over there, an > event that is no longer in the future, etc). > > I'm honestly just surprised that nobody has ever encountered a scenario > where they would need something like this before in Django. I can't be the > only one running scripted demos of a product with potential clients. Seems > like there would be a "django-demo" app for this or something. If you guys > help me figure out a good way to do this, I'll be happy to distribute it on > PyPi. > > Thanks again for the help guys. > Hmm, ok. Something that iterates through each model installed, checks its fields to see if it is a date field, and then rebases it based upon todays date and the date of the previous demo (so it knows the date is demo date + N). Try this, it's fairly naive, but it does the trick. https://github.com/tevansuk/django-demo-reset Cheers Tom -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
