On 12/20/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
On 12/19/06 5:12 PM, Russell Keith-Magee wrote: > There are only two things that could be considered non-backwards > compatible: > 1) The renaming of the inital_data targets to custom_sql How about we keep the initial data targets around, but just have 'em spit a "this function has been renamed to custom_sql" message? Once everyone's had a chance to adjust, we can kill the old names (next official release, perhaps).
+1, and done.
> 2) The slowdown associated with flushing the database at the start of > each doctest. Kinda annoying -- being able to run tests fast is, of course, nice -- but not when testing "correct" is better than "fast", I'd say. Plus, from my fooling around on my laptop, it doesn't really feel much slower to me... are you seeing a big slowdown?
Running the full 68 test system test: SQLite goes from ~20s to ~250s Postgres goes from ~25s to ~500s. Admittedly, this is on a G5 iMac, and I haven't spent a great deal of time tuning things, and I have the usual panoply of background processes. I take it you're not seeing anything like this sort of slowdown?
Yup, sounds good to me. Probably would be nice to make ``installfixture`` also understand a path argument as well so I can use it to import some data I've got on the filesystem somewhere...
Ok; I've modified the loader such that you can specify a fixture as: - foo (attempts to discover available fixtures) - foo.json (explicit type) - foo/bar (discover type, traversing a subdirectory) - foo/bar.json (explicit type, traversing a subdirectory) - /foo/bar (discover type, looking in a root directory) - /foo/bar.json (explicit type, looking in a root directory) If you specify a file extension, it will only load that fixture type; if you leave it up to discover for itself, it will try all available types, load the first one it finds, and raise an error if there are two fixtures with the same name in the same directory. I wasn't thinking straight about dumpdb - you still need a --format option, because it outputs to stdout, not a file. The arguents to dumpdb are the apps you want to dump.
> How would loaddb differ from installfixture? Duh, it wouldn't, of course. I think I missed the orthogonality between ``dumbdb`` and ``installfixture`` -- they don't seem to be opposites with hte current naming.
Agreed.
Hm... export/import? dump/load? exportdata/importdata? dumpdata/loaddata? I think I like those last two... anyone else wanna chime in?
dumpdata/loaddata works for me. I've renamed them as such; unless there are any other suggestions...
>> * I think ``syncdb`` should indeed automatically install some >> fixture. I'm >> not a huge fan of naming it "post_syncdb", but that's OK if we can't >> come up >> with a better name. > > I only picked that name for parity with the signal (which are publicly > exposed by virtue of the management.py hack). Other candidates I > played with: init, initial, initdata. I like ``initial.<format>``... ``initialdata`` could be good, too.
I think I prefer initial_data, for a combination of legibility and parity with loaddata/dumpdata.
I like (a), too; I'd say that if you've got initial data in two different formats that should cause an error. Undefined data modifying behavior scares me :P
See above; you can have multiple foo.json fixtures, but they must be in separate directories. If you have foo.json and foo.xml in the same directory, you get an error.
Yeah, that's totally true -- but at the same time, ``reset`` (when it works) is a useful shortcut. In the absence of any sort of usable schema migration tools, I'd say leave it in.
I can live with that.
Let me know if there's any part of these changes you'd like me to tackle; I'm gonna have a bunch of free time over the holiday break, and I think that fixtures would make a pretty nice Christmahannukwanzaka gift to the Django community :)
I've implemented most of the changes you suggested. I am currently chasing a minor issue with rolling back transactions when a repeated fixture name is found, but otherwise, I should have a revised patch in the next day or so (Christmahannukwanzaka rush permitting). The only bit that is missing at this point is the legacy flush implementation (including identifying pre 8.1 postgres installs). If you want to pitch in there, I'd be much obliged. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
