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).
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?
If people are happy with these two changes, I'm happy to commit.
I'd like to hold off until we can get Adrian's feedback, but other than that
I'm pretty thrilled with this stuff, actually :)
True. Ok; how about this,
./manage.py installfixture foo.json
would install the JSON fixture foo, wherever it can be found; the
TestCase setup just names files (as per your example), and the
--format option disappears, with dumpdb using the extension to
determine the serializer to use.
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...
* I'm fine with JSON being the default fixture format. I have half a YAML
serializer written, but the dependency on Syck makes using it as a
default
problematic. Anyone know of a pure-Python YAML library with a license
liberal
enough to ship with Django?
No default required if we make extensions explicit. Problem solvered.
Hooray for two birds and all that :) I'll have to wrap up my YAML serializer...
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.
Actually, now that I think about it, what about naming those functions
"backup" and "restore"?
+1 to backup, +0 to restore. Installfixture is a little bit ungainly,
but 'restoring a fixture' doesn't seem quite right. The only other
option that comes to mind is 'prime' (in the 'prime the fuel lines'
sense). Any other suggestions?
Hm... export/import? dump/load? exportdata/importdata? dumpdata/loaddata?
I think I like those last two... anyone else wanna chime in?
* 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.
The only difficulty here is which fixture to load - in the revised
design, you explicity name 'foo.json', so the format is known; syncdb
could either
a) try all extensions (try to load 'init.json', 'init.xml', ...), or
b) pick on one format (initdata must be in json format).
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
* To solve the ``flush`` problem, I'd suggest just adding a method to
fall back on a drop/restore -- that should work anywhere, right?
Yes. However, it would be painfully slow. Glacially slow. Slower than
a wet week in Wichita slow.
Well... we here in Lawrence like to look down on those from Wichita, but in
this case it's better than nothing, I suppose.
Also - can you use psycopg to work out the version of the underlying
Postgres database? If not, how would I determine that a user has a
post v8.1 version of Postgres?
You could always run a "select version();" -- it'll look something like
'PostgreSQL 8.1.3 on i686-apple-darwin8.6.1, compiled by GCC
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5332)'.
I'm not sure that psycopg can tell you without making a connection anyway --
libpq's pretty compatible between versions, so psycopg could connect to a
number of different versions of postgres.
The problem is that reset doesn't really work, and I'm not sure fixing
it is a non-trivial problem. I started out trying to use reset in the
fixtures, but I quickly found out that if there are any cross table
dependencies, you can't just reset an app (at least, not under
postgres) - the constraints kick in and prevent table deletion. I
tried fixing it, and I just ended up tying myself in knots trying to
resolve circular dependencies in table references.
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.
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 :)
Jacob
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
