Re: suggestion for ticket #8618, Many-to-many intermediary with multiple foreign keys
On Mon, Oct 6, 2008 at 1:04 AM, SliceOf314
<[EMAIL PROTECTED]> wrote:
>
>> My personal preference for that ticket is that the annotation to say
>> which foreign keys to use should belong on the model for the
>> intermediate table, not adding to the declaration of the connecting
>> models.
>
> That is a very fair point. Therefore, how does the following sound?
>
> class Vacation(models.Model):
># my suggestion
>person = models.ForeignKey(Person, from_m2m='vacations')
>location = models.ForeignKey(Location)
>date = models.DateField()
>travel_agent = models.ForeignKey(Person,
> related_name='booked_vacations')
I would be inclined to put the setting in the Meta block. Under your
proposal, the setting is tied to the key, but the setting isn't really
controlling the behaviour of the key - it's controlling the way the
model as a whole is interpreted. Having the setting on the key would
mean it is exposed on every foreign key - not just the ones in M2M
tables.
For example:
class Vacation(Model):
...
class Meta:
through = ('person', 'location')
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 django-developers@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Oracle testing wanted
On Oct 5, 6:23 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Can somebody with access to Oracle please try out the patch in #9307.
> It's an attempt to allow pickling of the Query class used by the Oracle
> backend.
>
> The most basic test is probably to create any kind of Queryset using
> "manage.py shell" and the pickle.dumps(my_queryset.query) and see if it
> works. Then try reloading that (pickle.loads(...)).
>
> The other test is anything using caching, the obvious one typically
> being the query regression tests ("runtests.py --settings=... queries"),
> since there's a test for Queryset pickling in there. Note any problems
> on the ticket and I'll address them. Hopefully I've avoided the most
> obvious bozo errors (no guarantees, however) and there should be enough
> clues in the patch to self-diagnose the most obvious problems if not.
>
> Regards,
> Malcolm
I will test this, but I also want to point something out. I see a lot
of talk about developers not having access to Oracle, but that is
wrong. Oracle is free for non production use. From Oracle's website:
All software downloads are free, and each comes with a Development
License that allows you to use full versions of the products only
while developing and prototyping your applications (or for strictly
self-educational purposes).
So there is no reason a developer can't install Oracle for testing. At
work, our product uses Oracle so we install it all the time in VMWare,
all the workstations, etc. When in tech support here, I had to tell a
lot of customers they can install Oracle on as many test systems as
they want, it is just production systems that Oracle cares about.
Actually installing and configuring Oracle is a different matter if
you are not familiar with it, but I think the defaults should be
decent for testing. Also, if you are developing off a computer with
limited resources, you may not want to install Oracle.
See here for their downloads overview and the database download page:
http://www.oracle.com/technology/software/index.html
http://www.oracle.com/technology/software/products/database/index.html
If everyone already knew this, I apologize, but like I said, I see a
lot of people saying they don't have access to it.
Thanks,
John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Oracle testing wanted
On Oct 6, 10:54 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > On Mon, Oct 6, 2008 at 9:33 AM, varikin <[EMAIL PROTECTED]> wrote: > > Oracle is free for non production use. > > That's not what we mean when we say we don't have access to Oracle... > > > Actually installing and configuring Oracle is a different matter if > > you are not familiar with it, > > ... this is. > > > but I think the defaults should be decent for testing. > > They're not. Installing Oracle on Debian/Ubuntu is incredibly easy > (add an entry to apt sources and apt-get install oracle). However, > that doesn't actually set anything up, or configure a database, or > whatever. And so the next step is to read through thousands of pages > of badly organized terribly written documentation. > > Sorry, but I really do have better things do to. > > > Also, if you are developing off a computer with > > limited resources, you may not want to install Oracle. > > This is also a big deal: I can run MySQL and PostgreSQL on my > shitty-ass PC, but simply starting Oracle shoots the load up through > the roof. > > OK, so that sounded a bit hostile; I'm sorry! None of this is your > fault (obviously) but you did want to know why none of the core devs > have Oracle installed :) I just get all ranty when Oracle's > involved... > > Jacob I agree with your points. I wouldn't use Oracle myself I didn't have to. I was just making sure people knew they could test with it if they absolutely needed to. And I completely agree with the thousands of pages of disorganized documentation. I have been forced to go through that stuff due to supported and developing something that uses Oracle. John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~--~~~~--~~--~--~---
Oracle testing wanted
Can somebody with access to Oracle please try out the patch in #9307.
It's an attempt to allow pickling of the Query class used by the Oracle
backend.
The most basic test is probably to create any kind of Queryset using
"manage.py shell" and the pickle.dumps(my_queryset.query) and see if it
works. Then try reloading that (pickle.loads(...)).
The other test is anything using caching, the obvious one typically
being the query regression tests ("runtests.py --settings=... queries"),
since there's a test for Queryset pickling in there. Note any problems
on the ticket and I'll address them. Hopefully I've avoided the most
obvious bozo errors (no guarantees, however) and there should be enough
clues in the patch to self-diagnose the most obvious problems if not.
Regards,
Malcolm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: suggestion for ticket #8618, Many-to-many intermediary with multiple foreign keys
through sounds a little odd to me, as Vacation is the table 'through' which
the m2m is made. Shouldn't it be 'in_between' or something the like here?
(As Vacation is kind of 'in between' Person and Location)
just my 2p.
TiNo
On Mon, Oct 6, 2008 at 2:44 AM, SliceOf314 <[EMAIL PROTECTED]>wrote:
>
>
> > For example:
> >
> > class Vacation(Model):
> >...
> >class Meta:
> > through = ('person', 'location')
> >
> > Yours,
> > Russ Magee %-)
>
> Sounds good to me. Unless someone else has a better suggestion, I
> will go ahead and start work on a patch.
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Oracle testing wanted
On Mon, Oct 6, 2008 at 9:33 AM, varikin <[EMAIL PROTECTED]> wrote: > Oracle is free for non production use. That's not what we mean when we say we don't have access to Oracle... > Actually installing and configuring Oracle is a different matter if > you are not familiar with it, ... this is. > but I think the defaults should be decent for testing. They're not. Installing Oracle on Debian/Ubuntu is incredibly easy (add an entry to apt sources and apt-get install oracle). However, that doesn't actually set anything up, or configure a database, or whatever. And so the next step is to read through thousands of pages of badly organized terribly written documentation. Sorry, but I really do have better things do to. > Also, if you are developing off a computer with > limited resources, you may not want to install Oracle. This is also a big deal: I can run MySQL and PostgreSQL on my shitty-ass PC, but simply starting Oracle shoots the load up through the roof. OK, so that sounded a bit hostile; I'm sorry! None of this is your fault (obviously) but you did want to know why none of the core devs have Oracle installed :) I just get all ranty when Oracle's involved... Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Oracle testing wanted
> Oracle is free for non production use. Sort of -- there are some limitations, e.g., you aren't allowed to develop GPL-licensed using their 'free' license. > but you did want to know why none of the core devs > have Oracle installed :) I have the dev version installed on a Windows VM, and the official Oracle maintainers (Ian Kelly and Matt Boersma) have their own commercial installation. We drink the Oracle kool-aid so the other devs don't have to. Regards, -Justin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Re-thinking model validation
On Oct 6, 2:03 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sun, 2008-10-05 at 14:11 -0700, mrts wrote:
> > Looking at the path Honza has taken [1], it looks that it both
> > complicates things and causes overhead -- for every constraint on
> > an model object, an extra db call for checking it is made,
> > instead of relying on the constraint checks enforced by the db
> > backend and corresponding exceptions during `save()`
> > (e.g. for uniqueness validation, one db call is needed to check
> > the uniqueness constraint and a second one to actually save the
> > object).
>
> Except that very few validation requirements correspond to database
> constraints (for example any reg-exp matching field, or limits on an
> integer, etc). We aren't about to require database check constraints for
> all of those. So it's not really a one-to-one in practice. You've
> misread the patch quite badly,
Now that I re-read the first section of my post I do see that I made
the mistake of being over-emphatic and made an incorrect
generalization ("for every constraint on an model object, an extra db
call for checking it is made") -- sorry for that. My point was that
validating non-db constraints (like regex matching of an EmailField)
could remain the responsibility of form validation as it is now. So,
as presently, forms layer could take care of everything that can be
taken care of without touching the database (including max_length, not
null and choices) and model forms take additionally care of
IntegrityErrors by catching them, augmenting _errors[] with relevant
data and re-throwing them. And as IntegrityErrors can only be reliably
caught during save(), model forms have to be handled differently.
I had mostly backwards-compatibility and simplicity in fixing e.g.
#8882 in mind (as validate_unique() in forms/models.py lets
IntegrityErrors through anyway as of 1.0 and can not be relied on).
But if you think this is a bad idea, so be it.
- copied from below: -
> There needs to be a clear phase prior to saving when
> you can detect validation errors so that they can be correctly presented
> back to the user. You see this already with forms where we check for
> validity and, if it's not valid, we present the errors. If it is valid,
> we move onto doing whatever we want with the data (saving it or
> whatever).
General model validation is of course conceptually correct and good --
if the responsibility assignment between form and model validation is
sorted out in non-duplicated and elegant manner, unique checks handled
efficiently and if the code lands in a month or two timeframe, then
all is well. Meanwhile, people who want to use inline formsets with
unique validation are stuck on #8882 (as it looks that it takes quite
an effort to fix that with the current codebase -- and I'd like to be
wrong here).
> it sounds like: only the unique
> requirements have to check the database (and a pre-emptive check is
> reasonable there, since it's early error detection and there's only a
> small class of applications that are going to have such highly
> concurrent overlapping write styles that they will pass that test and
> fail at the save time).
- copied from below: -
> The only time there's any kind of overlap is when there's a database
> constraint such as uniqueness which we cannot guarantee will remain true
> between the validation step and the saving step. So there's a chance
> that save() will raise some kind of database integrity error. But that's
> actually the edge-case and in a wide number of use-cases it's
> practically zero since you know that your application is the only thing
> working with the database.
And your take is just to ignore that case and actually let e.g. admin
display 500 pages? It's an ordinary race condition (some of which are
indeed rare in practice but nevertheless usually taken care of) and
you yourself have generally advocated pushing this kind of problems to
the relevant backends -- which is nice and proper. Applying the same
principle to this case as well (and I can't think of anything other
but try save/catch IntegrityError) seems to me the only viable way to
avoid the race.
And I don't buy the "your application is the only thing working with
the database" argument -- it is, but it happens to be multi-process or
-thread. How am I supposed to avoid that thread or process A and B do
a validate_unique() for some x concurrently, finding both out that it
doesn't exist and proceed happily with saving, so that one of them
chokes on an IntegrityError?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
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
-~--~~~~--~~--~--~---
Considering alternate SQL Code generators
I was taking a look at Ticket #3163 which, when incorporated into Django, would add a Meta flag to the model which disables SQL code generation. It occurred to me that on a conceptual level, this fix is wrong. What would be more generally useful is a dictionary of alternate SQL code generating plugins. You could then plugin a custom SQL generator by name in a given model Meta class. With this approach you could create plugins that would create alternate table formats such as partitioned tables, or app-specific DB views or such. You could also create and use a plugin that generates no SQL at all which would handle the use case targeted by the fix to #3163. I haven't looked at the code enough to know where this abstraction layer fits best, but one obvious possibility is to have each "plug- in" take the form of a complete alternative db backend. Since this would then boil down to selecting the DB backend on a per model basis, this mechanism should probably be co-designed along with the multiple DB API since there might be some conceptual overlap. Thoughts would be appreciated before I jump in and do a deeper dive on this. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Oracle testing wanted
On Mon, 2008-10-06 at 07:33 -0700, varikin wrote:
[...]
> I will test this, but I also want to point something out. I see a lot
> of talk about developers not having access to Oracle, but that is
> wrong.
I have neither the disk space or the CPU power on my laptop to run the
Oracle tests in a VM in any practical sense. It's not merely difficult
or unbelievably time consuming; it's impossible. I used to have a 64 bit
machine that had Oracle installed on it (sometimes -- VMWare pretty
regularly broke with kernel upgrades, so I was often in a position of
not being able to run VMware because I chose to have other bug and
security fixes installed on my system) and it took hours to run the
Oracle test suite, particularly if something went wrong and I had to
untangle things from an intermediate state. These days I only have
access to a laptop that is quite a few years old now, so that option
isn't available to me any longer.
I've agreed to the Oracle developer license in the past (before I
started ever doing Django development work) and sometimes Oracle's
authentication server on their website was up for long enough I was able
to log in and download the developer edition ("unbreakable", my ass! The
backend to their website was broken pretty much all the time last year).
I'm aware it is possible to get a developer edition, but being able to
download a tarball isn't the sole requirement.
This is one of the very few areas I have to totally rely on other
members of the community to do the final piece of any development work I
do and I make no apologies for that.
Fortunately, in this case Justin has been able to do the requisite
testing and pointed out an assumption I missed in my fake testing. I
need to rethink the solution a little and probably hold my nose and
commit one fix to 1.0.X and a more holistic change to trunk. I just need
to work out the details of that second piece first to avoid too much
churn.
Regards,
Malcolm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
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
-~--~~~~--~~--~--~---
