Or there's overriding the metaclass...
On Mon, Dec 7, 2009 at 12:39 PM, Bill Freeman wrote:
> Hmmm. Probably just as ugly, and untested, but:
>
> class A(basemodel):
> for o in range(MAXNUMREDPORTS):
> for i in (1,2):
> locals()["Port%d_redfield%d" % (o+1, i)] = models.Flo
Hmmm. Probably just as ugly, and untested, but:
class A(basemodel):
for o in range(MAXNUMREDPORTS):
for i in (1,2):
locals()["Port%d_redfield%d" % (o+1, i)] = models.FloatField()
...
On Mon, Dec 7, 2009 at 12:10 PM, Daniel Goertzen
wrote:
> Okay, I explored model gener
Unless I'm very confused, django will happily delete your related
objects (since they
don't have anything to relate to anymore). Many to many would be more
problematic.
As far as creating a set of ports, you were stuck with that anyway, if
I understand
your original approach correctly. Even if y
On Dec 7, 8:56 am, Daniel Goertzen wrote:
> Thanks for the reply Bill. The problem I had with that approach is that
> after creating the product I have to worry about creating red and green
> ports. Likewise, upon deletion, I have to mop up the ports. Looking
> through the documentation, I di
Okay, I explored model generation a bit and found an approach that wasn't
too offensive. For those that are trying to solve the same problem that I
am, here is what I came up with:
def red_port(prefix):
return """
%(prefix)sredfield1 = models.FloatField()
%(prefix)sredfield2 = models.FloatFie
Thanks for the reply Bill. The problem I had with that approach is that
after creating the product I have to worry about creating red and green
ports. Likewise, upon deletion, I have to mop up the ports. Looking
through the documentation, I did not find a way to bury this behavior in the
Model.
I'm not clear on what you need to store, so I'll assume that you have individual
data to store for each port of each type, and it is unrelated to data stored for
another instance of the same or a different product.
What comes to mind is that there is a "Product" model and a "Port" model (or if
red
Each port would have about a half-dozen fields, and different port types are
totally different from one another. I won't be querying port fields.
I've thought about your JSON field trick before, but not with the nice
wrapper methods. Good idea, thanks!
The solution does have flaws, but if nothi
What kind of information will the database have to store about the ports
themselves?
How will you need to be able to filter querysets by information in the port
fields, if at all?
I'm going to throw this one solution out there, but depending on your needs it
may not fit:
Create a red_ports co
On 25 juil, 14:49, Tim Chase <[EMAIL PROTECTED]> wrote:
> When you add a foreign-key to your model, the referenced model
> gets a psedudo-attribute, usually called _set which is
> the set of s that have this attribute. By adding the
> related_name, you provide a way to reference the Units for whi
>>responsable = models.ForeignKey('Personne', ...)
>>
>> if you need to forward-reference a model that hasn't yet been
>> defined.
>
> thanks for the anwser.
> I dont saw this particular sentence.
The magic is in the phrase "If you need to create a relationship
on a model that has not yet b
>
>responsable = models.ForeignKey('Personne', ...)
>
> if you need to forward-reference a model that hasn't yet been
> defined.
thanks for the anwser.
I dont saw this particular sentence.
But now I have this message:
directory.unite: Reverse query name for field 'responsable' clashes
with
> I like to do something like that in a app models.py:
>
>
> class Unite(models.Model):
> responsable = models.ForeignKey(Personne, verbose_name='The
> Chief', blank=True)
> ...
>
> class Personne(models.Model):
> unite = models.ForeignKey(Unite,null=True)
>
>
>
> And I h
13 matches
Mail list logo
