Re: Changing the value of the primary key
On Jul 18, 7:41 am, Torsten Bronger <[EMAIL PROTECTED]>
wrote:
> > Can I ask why you would need to change PKs?
>
> Yes. We are a scientific institution, and I create a samples
> database. Frequently a sample gets a new name, however, the old
> name(s) must be kept as aliases.
>
> For the aliases, I probably will use a second table with many-to-one
> relationship.
>
> I wanted to keep the (current) sample name the primary key because I
> think that this accelerates lookup, but if all else fails, I must
> use a surrogate key.
Clearly, a growing set of names is not a sufficiently unique and
immutable primary key for your data. I'd suggest something like a
composite key made of date/time, sample no., and fk to experiment
(whatever an experiment's pk is), but django doesn't support composite
keys. So a "surrogate" is a good compromise here. As for names, since
each sample can have multiple names, it should be a separate table
with a foreign key to the samples table.
class Experiment(models.Model):
date = ...
etc
class Sample(models.Model):
experiment = models.ForeignKey(Experiment)
date = models.DateTimeField()
sampleno = models.PositiveIntegerField()
... data ...
class Meta:
unique_together = (('experiment', 'date', 'sampleno'),)
class SampleName(models.Model):
sample = models.ForeignKey(Sample)
name = models.CharField(max_length = 60)
named = models.DateTimeField()
Primary keys never change over time.
-Jim
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Re: Accessing Components of a MultipleChoiceField
This is similar to my question about radio boxes. I hacked in a solution, but I haven't found a proper one yet. Maybe we should raise the issue on the developer's list? [0] http://groups.google.com/group/django-users/browse_thread/thread/0707e4e3665e9cb0# On Jul 11, 3:57 pm, Tim <[EMAIL PROTECTED]> wrote: > I would like some finer control over the display of a > MultipleChoiceField, but I'm not sure how to get to the individual > components (in my case, checkboxes). For example, if I define the > field in the form like so: > > tags = > forms.MultipleChoiceField(widget=forms.CheckboxSelectMultiple, > choices=tag_list,) > > then I would like to be able to control the resulting HTML of the > individual checkboxes, and not just the checkboxes with label wrappers > as a whole (via as_p or as_table or whatever) - I thought it might be > possible to access by name or id (since forms has access to this > information during rendering), but that doesn't seem to be the case. > > Any ideas? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Two edit_inlines between the same two models?
I might try setting up Trip without direct reference to the QMs, and QMs with two references to Trip: class Trip(models.Model): ... trip stuff ... class QM(models.Model): found_during = models.ForeignKey(Trip, related_name=''found_qms") killed_during = models.ForeignKey(Trip, null=True, blank=True, related_name="killed_qms") ... trip stuff ... and maybe a few convenience methods and properties: (in Trip): @property def live_qms(self): return self.found_qms.filter(killed_during=None) (in QM:) @property def status(self): return self.killed_during == None and "Live" or "Dead" -Jim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
newforms - display only one radio button of a group?
Hi folks. I'm building a form for entry of addresses. Users will have
the option of using a structured st of input fields (appartment,
street number, street name, etc.) or using a freeform input (one large
input field for things like "Smith Acreage, RR5, 20 mins South of
city"). They chose between the two using a radio button. I've
implemented this radio button as a ChoiceField with the RadioSelect
widget.
Now I'd like to hand-layout the form, so that one of the radio buttons
is next to the structured inputs, and the other is next to the
freeform input. I can write the input and label tags manually except
for one issue: I can't access the checked state of the radio buttons
through the BoundField the form gives me.
What is the Djangonautic solution to this? I got past the issue by
extending BoundField with a __getitem__ method which calls down into
the RadioSelect widget, which is slightly modified to know how to
return single radio fields, so now I can write {{ form.address_type.
0 }}. I don't like running a patched Django, though.
Ideas?
Thanks,
Jim
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Re: non editable admin model
I believe the permissions system, part of the auth app, can help you here. It won't prevent your admin superusers from changing things, but you can assign other users view, change and delete permissions on models. On Jul 3, 8:14 pm, Bobby Roberts <[EMAIL PROTECTED]> wrote: > Got a weird question. I have a need to make it so that we can search/ > view a certain model in the admin section but not add or edit. is > this possible? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Stability of trunk and 1.0 target: experience, testimonials?
Thank you, everyone. That was exactly what I needed. It looks like we'll be starting a prototype on Django trunk targeting 1.0 this week. Jim Meier --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: initializing a model with a dicitonary
On Jul 1, 10:56 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > c = Customer(first_name = customerdict['first_name'], last_name = > customerdict['last_name']).save() try c= Customer(**customerdict) > What am I doing > wrong? Not reading your python manual :) http://docs.python.org/ref/calls.html --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Stability of trunk and 1.0 target: experience, testimonials?
Hi folks, I'm trying to champion Django trunk/1.0 as part of a small project in a mid-sized city newspaper office. There is some worry about choosing a framework which does not currently have a stable release. I've been addressing these worries with examples of the stability of trunk and the excellent planning and engineering of the project in general. Never the less, it would be valuable to me to have testimonials from others using or targeting trunk/1.0 in their applications, especially from traditional businesses. I think such testimonials could also help others get steam behind the 1.0 effort in organizations which are wary of support and stability. So I'd like to request that, if you have time and inclination, such users would post or email testimonials explaining your use of Django, experience with it's stability over time, confidence in the core developers, and (and here's where the higher-ups are interested) the size and nature of your project and company. Please help us avoid PHP! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
