Hi Malcolm
This is one of those cases where I have to ask why you're using a class
> instead of a dictionary. You're mapping keys (initialisation parameters)
> to values (the values to set the parameters to). Using a map object
> seems like the way to go. It doesn't carry the necessary indentation
> requirements with it, for a start.
>
This is just the way fixture does it, I found it a bit of a paradigm shift
at first, but I actually really like it now, for one thing it allows you to
do:
class app__Model(DataSet):
class generic_instance:
field_one = ...
.... lots of other generic fields here
class another_instance(generic_instance):
different_field = ...
other_overridden_field = ...
In this instance you can define fields on generic_instance that will be
present unless overridden in another_instance. I also allows for the
mechanism of referring between DataSets. See
http://code.google.com/p/fixture/source/browse/trunk/presentations/ for more
of that back story, usage and motivation behind fixture.
>
>
> I'd look at that approach first. Looks like you'd need to override the
> _pre_setup() method. This seems like a very easy question to answer. Why
> isn't the "yes" just the obvious answer? Is there some hidden shoal in
> there?
The testing landscape has changed a bit since I looked in detail, and
DataSets are loaded in a transaction as well so I guess the waters are
potentially a bit cloudy WRT transactions and fixture loading. Fixture also
provides some niceties for loading fixtures so it may come down to a choice
of a fairly vanilla subclass of unittest's TestCase as opposed to a subclass
of django's overriding _pre_setup()
>
> This is one of those things I'm going to have to postpone for a while
> until I have more time. You're on the boundary of repeating a bunch of
> internal code (particularly from django.db.models.base.Model) by the
> looks of it, without constructing models. I'd be looking at closely
> whether you can reuse more of the existing stuff.
Yes this was what I was getting at really, it's been some time since I
played around with the internals of django models, (pre qsrf) so things have
changed a bit. I'd much rather do this with existing django code the roll my
own stuff which is overly familiar with django's privates so to speak!
>
> One general observation: The existing fixtures code, for all its
> edge-case fragility, doesn't seem to have any real design constraints
> stemming from the requirement that it creates Model instances and saves
> them (calling Model.save_base(raw=True)). Any particular reason you're
> not going down that path? You'd get all the error checking for free.
This was what I was after... I wasn't going down that path because I didn't
know about it, thanks for the steer! :-)
>
>
> You also don't avoid the problems such as MySQL + InnoDB not having
> deferrable constraint checking: none of that is a restriction of the
> Model layer.
Sound far preferable to the way I've done it then.
>
> Try to implement the reverse direction as well, but don't lose sleep if
> you can't, I'd suggest. :-)
>
> When you have access to the models, you know the names Django uses to
> refer to them, so you can use the same names in the fixture
> descriptions. For example, If Child -> Parent, exists, then the Parent
> fixture could define stuff for "child_set" (or the right related name).
That's pretty much what I thought. I started off this way to constrain what
I would have to cater for, but it would seem reasonable and more flexible to
let people so it either way. The one case where it might not work would be a
non-nullable ForeignKey. I will investigate, I have a suspicion that fixture
might have catered for this already.
>
> In the past (not Django, but in general coding), I've found it
> beneficial to write unit tests for third-party code to ensure it doesn't
> change some piece of behaviour we were relying on (or that our patched
> version didn't forget to be patched). Being able to specify fixtures for
> all related models in those cases could be useful. It's a question of
> how strictly you want to define the word "unit" in "unittest" (and
> Django takes a pretty liberal position there, which isn't necesasarily a
> bad thing). You've currently said that people can test an app and
> everything it refers to. But not test things that depend on that app.
> That's not a horrible restriction: facing only in the direction of
> upstream dependencies. But if you can make it worth both ways, why not?
Yep, this would be quite a nice aim, if an upstream app already had tests
and was using fixture, then you could use those fixtures to provide the data
where your models are referring to the existing ones.
Thanks for your time on this Malcolm, it's certainly given me an idea of
what to look at next and where I might be reinventing the wheel!
Cheers,
Ben
--
Regards,
Ben Ford
[email protected]
+447792598685
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
