On 12/20/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
I'm +1 on checking this into trunk right away -- as far as I can tell it's
completely backwards-compatible, right? Unless anyone objects -- and of
course after Adrian's given the OK -- are you happy enough with this to check
it in?
There are only two things that could be considered non-backwards compatible:
1) The renaming of the inital_data targets to custom_sql
2) The slowdown associated with flushing the database at the start of
each doctest.
If people are happy with these two changes, I'm happy to commit.
With that said, here's my feedback, in no particular order:
* I'm a big fan of reusing the serialization framework for this. Am I right to
think that adding support for other fixture formats would be as easy as adding
new serialization formats?
Correct. Bring on the YAML.
* I prefer your "mistaken" syntax for ``django.test.TestCase.fixtures`` (i.e.
a list instead of a dict). It seems that Django could easily derive the format
from the extension, no? Or, you could manually give the extension::
class MyTest(django.test.TestCase):
fixtures = ["foo.xml", "bar.json"]
I kinda like that, one, actually -- explicit is better than implicit.
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.
* 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.
Can't help out with a YAML library, though.
* ``dumpdb`` == awesome. We should probably add a "loaddb" command at some
point; that would neatly let people move data from one database engine to
another (i.e. sqlite for testing to postgres for deployment). Nifty.
How would loaddb differ from installfixture?
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?
* 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.
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'd probably pick (a), but it does leave open the possibility that
multiple fixtures could be installed (init.xml and init.json in the
same directory). Installation order then becomes an unpredictable
thing, since the serializer order isn't guaranteed.
* 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.
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?
* I'm +1 on removing ``install`` -- ``syncdb`` should completely replace it.
However, ``reset`` is quite useful in the early stages of designing models;
it's quite useful to be able to drop/recreate an app all at once. Why exactly
would you want to remove it?
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.
* We need some docs written. I'm happy to do it when I get a chance, but it
might take a while. If any lurkers are reading this far down, contributing
some documentation of fixtures as a patch against the testing doc would help
immensely.
I wanted to get consensus on the design before I started cranking out
the docs. However, any contributions greatfully accepted.
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
-~----------~----~----~----~------~----~------~--~---
