foreign_key limiting choices
Robert
I'm writing a small app. for wifi network management.
In a "computer" model there is an "ext_ip" field which is a ForeignKey
to "Ext_ip" model.
When adding/modifying a computer, I can use a select one from ext_ips
list.
The problem is that I need to select only from ext_ips not used by
another computer.
What is the best way to accomplish this ?
Do I need to play with raw sql or I missed anything when played with an
API ?
Maybe this/my models should be done a different way ?
Thanks,
Robert
Malcolm Tredinnick
> Hello,
>
> I'm writing a small app. for wifi network management.
>
> In a "computer" model there is an "ext_ip" field which is a ForeignKey
> to "Ext_ip" model.
>
> When adding/modifying a computer, I can use a select one from ext_ips
> list.
>
> The problem is that I need to select only from ext_ips not used by
> another computer.
>
> What is the best way to accomplish this ?
> Do I need to play with raw sql or I missed anything when played with an
> API ?
Is the limit_choices_to option on ForeignKey fields of use to you
(scroll down to the options in
http://www.djangoproject.com/documentation/model_api/#many-to-one-relationships )?
If you can extract your choice list via simple filtering on a queryset,
then this should do what you want.
Regards,
Malcolm
Robert
this should be done. I've read it many times.
I only see eq, exact etc. options, which I don't see useful according
to my (toll Django/Python newbie)
knowledge. I don't see any limit_choices_to Queryset (other thatn dict)
example?
I don't know how to put a subselect or other comparison to check
whether the specified ext_ip (Ext_ip model)
has been already "attached" to the computer (Computer model).
Please shed some light on this.
Thanks for your previous response.
Robert
Robert
like limit_choices_to and Queryset :-(
I've wrote a new function
class Computer(models.Model):
def getFreeExtIP():
some instructions for specifying a tuple here
returning a tuple
ext_ip = models.IPAddressField(choices = getFreeEXTIP(), ...)
Thanks,
Robert
Darren Redmond
hi all,
I have been using django with postgres on windows while builiding my
application for the last month or so.
I have just spend the day putting the app onto a linux box. It has just
been pointed out to me by one of my colleagues,
while building psycopg on the linux box, that it is a Gnu Public License.
Now my understanding of GPL is that if a product uses it, it can't claim
to be BSD. So given that django imports psycopg dynamically,
how does Django maintain its BSD status?
Also has anyone else noticed this and how have other people got around
this issue when using a postgres backend?
worried ;)
Darren
tekNico
Disclaimer: this is not legal advice, read the fine print and decide
for yourself.
This is a FAQ (unfortunately not included in the PsycoPg FAQ).
Summary: usage of PsycoPg with OpenSSL and PostgreSQL libpq does not
extend the GPL license to the whole program.
Details follow.
>From http://initd.org/svn/psycopg/psycopg1/trunk/README:
Licence
-------
psycopg is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version. See file COPYING for details.
As a special exception, specific permission is granted for the GPLed
code in this distribition to be linked to OpenSSL and PostgreSQL libpq
without invoking GPL clause 2(b).
>From http://initd.org/svn/psycopg/psycopg2/trunk/LICENSE:
psycopg and the GPL
===================
psycopg is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version. See file COPYING for details.
As a special exception, specific permission is granted for the GPLed
code in this distribition to be linked to OpenSSL and PostgreSQL libpq
without invoking GPL clause 2(b).
Note that the GPL was chosen to avoid proprietary adapters based on
psycopg code. Using psycopg in a proprietary product (even bundling
psycopg with the proprietary product) is fine as long as:
1. psycopg is called from Python only using only the provided API
(i.e., no linking with C code and no C modules based on it); and
2. all the other points of the GPL are respected (you offer a copy
of psycopg's source code, and so on.)
--
Nicola Larosa - http://www.tekNico.net/
Baby, I can tell you there's no easy way out
Lost inside of dreams that guide you on
Baby, I can tell you there's no easy way out
Soon the guiding moonlight will be gone
-- David Sylvian, Silver Moon, Gone to Earth, 1986
James Bennett
> Now my understanding of GPL is that if a product uses it, it can't claim
> to be BSD. So given that django imports psycopg dynamically,
> how does Django maintain its BSD status?
Building a bit on Nicola's response, I feel it's useful to point out
that if an end user of Django chooses to use it in conjunction with
any GPL library, regardless of whether that library provides
exceptions like psycopg does, that use does not affect Django in the
slightest; the GPL explicitly places no restrictions on how you
personally use GPL software.
Also, if you yourself were to distribute Django and psycopg, or
distribute a Django application along with some other GPL library
which was required by the application, then you and you alone would be
required to offer Django under the terms of the GPL; actions taken by
someone "downstream" cannot propagate "upstream" to the main Django
distribution.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
Darren Redmond
Nicola,
Thanks for the prompt response.
Let's hope the explanation keeps our legal team happy, otherwise I need
another database.
cheers
Darren