On Thu, Jul 21, 2011 at 5:35 PM, Marc Aymerich wrote:
>
> ups, I think it should be:
> contract.products.filter(id=Y).values_list('rebate_pct', flat=True)
> product.contractproduct_set.filter(id=X).values_list('rebate_pct',
> flat=True)
Thanks. The first one does not work since rebate_pct is in t
On Thu, Jul 21, 2011 at 11:33 PM, Marc Aymerich wrote:
>
>
> On Thu, Jul 21, 2011 at 11:11 PM, nixlists wrote:
>
>> On Thu, Jul 21, 2011 at 4:30 PM, Jani Tiainen wrote:
>> > ContractProduct.objects.all()
>> > Following might work also (not sure, but is easy to test in shell for
>> > example):
>
On Thu, Jul 21, 2011 at 11:11 PM, nixlists wrote:
> On Thu, Jul 21, 2011 at 4:30 PM, Jani Tiainen wrote:
> > ContractProduct.objects.all()
> > Following might work also (not sure, but is easy to test in shell for
> > example):
> > for c in Contract.objects.all():
> > for cp in c.contractprod
On Thu, Jul 21, 2011 at 4:30 PM, Jani Tiainen wrote:
> ContractProduct.objects.all()
> Following might work also (not sure, but is easy to test in shell for
> example):
> for c in Contract.objects.all():
> for cp in c.contractproduct_set.all():
> print c, cp.product, cp.rebate_pct
> --
On Thu, Jul 21, 2011 at 10:50 PM, nixlists wrote:
> On Thu, Jul 21, 2011 at 2:17 PM, Jani Tiainen wrote:
> > Hi,
> > So you want to tie Contract with Product(s) with rebate_pct? You then
> need
> > custom intermediary m2m table say "ContractProduct"
> > https://docs.djangoproject.com/en/1.3/top
On Thu, Jul 21, 2011 at 2:17 PM, Jani Tiainen wrote:
> Hi,
> So you want to tie Contract with Product(s) with rebate_pct? You then need
> custom intermediary m2m table say "ContractProduct"
> https://docs.djangoproject.com/en/1.3/topics/db/models/#intermediary-manytomany>
> for more. So in the end
Hi,
So you want to tie Contract with Product(s) with rebate_pct? You then need
custom intermediary m2m table say "ContractProduct" https://docs.djangoproject.com/en/1.3/topics/db/models/#intermediary-manytomany>
for more. So in the end your models would probably look a alike following:
class Cont
Sorry about formatting. Also the there is a mistake.
"I'd like to define the Product model..." should be
"I'd like to define the Contract model...
Thanks.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to dja
The sample type table is only needed to generate a form for new samples.
> > The attribute table could be broken up by data type if necessary as well.
>
> > Sent from my Verizon Wireless BlackBerry
>
> > -Original Message-
> > From: llanitedave
> > Da
t;
> Sent from my Verizon Wireless BlackBerry
>
> -Original Message-
> From: llanitedave
> Date: Fri, 18 Jun 2010 23:27:55
> To: Django users
> Subject: Re: Database Design Question
>
> Thanks for the response, Venkatraman. You're right that I don't
> ant
Sent from my Verizon Wireless BlackBerry
-Original Message-
From: llanitedave
Date: Fri, 18 Jun 2010 23:27:55
To: Django users
Subject: Re: Database Design Question
Thanks for the response, Venkatraman. You're right that I don't
anticipate a huge number of records here -- a few
Hallöchen!
llanitedave writes:
> [...]
>
> I guess it's mostly a normalization question.
>
> And while I was typing out a long explanatory discussion to
> enlarge on the problem, I stumbled across the answer.
>
> I'll need to use a separate table for each sample type to store
> its unique set of
Thanks for the response, Venkatraman. You're right that I don't
anticipate a huge number of records here -- a few hundred thousand at
the extreme high end. Sharding isn't something I considered, and I
don't think it would be necessary.
I guess it's mostly a normalization question.
And while I w
On Sat, Jun 19, 2010 at 10:12 AM, Venkatraman S wrote:
> Prefer a table like follows (tblname:samples): sampleid, samplename ,
> sampledesc etc etc
>
Ok - i missed explaining why i would recommend this:
In most of the applications, maintainence is a bigger pain than development.
In your case,
On Sat, Jun 19, 2010 at 4:28 AM, llanitedave wrote:
> I'm putting together a system to track scientific samples of various
> types. The "various types" is what's making me scratch my head at the
> moment.
>
Prefer a table like follows (tblname:samples): sampleid, samplename ,
sampledesc etc e
Validation turns out to be well-nigh impossible using parent / child
aliases, but pretty easy with parent / child accounts. Here's what
I've ended up with:
class Account(models.Model):
user = models.ForeignKey(User, unique=True, null=True, blank=True)
alias = models.CharField(ma
I'm not asking as a Django / foreign key thing. I'm having a lot of
trouble referencing each model from the other's save method for
validation purposes, because there's always going to be one that's
declared after the other.
On Aug 19, 10:35 am, Joshua Russo wrote:
> You can, it just creates
You can, it just creates headaches. At least one of the ForeignKeys needs to
not be required (I believe that's the default anyway).
On Wed, Aug 19, 2009 at 1:27 PM, ringemup wrote:
>
>
> Is having two classes that reference one another just simply something
> that can't be done in Python?
>
>
>
Is having two classes that reference one another just simply something
that can't be done in Python?
On Aug 19, 4:36 am, Joshua Russo wrote:
> On Tue, Aug 18, 2009 at 11:04 PM, ringemup wrote:
>
> > Well, I'm trying to implement parent / child aliases, but I'm running
> > into problems with
On Tue, Aug 18, 2009 at 11:04 PM, ringemup wrote:
>
> Well, I'm trying to implement parent / child aliases, but I'm running
> into problems with class declaration order because I need to reference
> the Alias class from within the Account class as well as referencing
> Account from Alias for valid
Well, I'm trying to implement parent / child aliases, but I'm running
into problems with class declaration order because I need to reference
the Alias class from within the Account class as well as referencing
Account from Alias for validation purposes -- and not just in
ForeignKey declarations a
On Tue, Aug 18, 2009 at 8:26 PM, ringemup wrote:
>
> I have accounts that can have multiple aliases, but each account must
> have a primary alias. I can think of two ways to institute this, but
> they both have problems:
>
> 1) reference the primary alias from the account:
>
> class Account(mode
Yup, that could work too. Let me know what you end up with.
On Tue, Aug 18, 2009 at 9:58 PM, ringemup wrote:
>
>
> Yes, I think that does make sense. Thank you!
>
> While pondering this, I also came up with a third option, which is to
> make the alias data part of the Account model, and allow A
Yes, I think that does make sense. Thank you!
While pondering this, I also came up with a third option, which is to
make the alias data part of the Account model, and allow Accounts to
have parent accounts; then only accounts with no parents are permitted
to be assigned to users. (Also prohibi
Hi Doug,
On 4/26/07, Doug Van Horn <[EMAIL PROTECTED]> wrote:
> [Links]
> There's no harm in having unique columns in addition to your primary
> key (as you describe). The nut of the problem around natural keys,
> IMHO, is that the rules that make them natural keys today can change
> such that t
On Apr 25, 3:16 pm, "Kai Kuehne" <[EMAIL PROTECTED]> wrote:
>
> I'm a bit confused on how do it 'right(tm)'. Is there a
> rule or how would you do it?
>
You're asking about surrogate and natural keys:
http://en.wikipedia.org/wiki/Surrogate_key
http://en.wikipedia.org/wiki/Natural_key
Why not do both. I've always preferred letting the database generate
an auto primary key (id in django) even if my usage is primarily a
different column for key. Storing an int isn't wasting much space,
what do you have to lose? I've got a users object for example that
requires a unique email
A point that I missed was the speed. Is method 1) maybe faster than method 2?
I think it could.. because in 1) there are only numbers stored as
primary_key and
not strings (which can be as long as 255 characters).
Speed is one thing.. but is there any other difference between the two methods?
Whi
Hi,
On 4/25/07, Mike Caldwell <[EMAIL PROTECTED]> wrote:
> I don't think there is a "right(tm)" way, but there are some things to
> consider. A lot of people would argue that a unique characteristic makes a
> very good primary key, I think I might be one of them. But, remember that
> data refle
I don't think there is a "right(tm)" way, but there are some things to
consider. A lot of people would argue that a unique characteristic makes a
very good primary key, I think I might be one of them. But, remember that
data reflects the real world. In general, a person's name isn't very
unique.
Mike Caldwell wrote:
> That is why governments invent things like SSN, to make you unique.
btw, don't use SSN as unique id 8)
Besides security and privacy issues, it's also not guaranteed to be
unique. At a previous job dealing w/ cell phone accounts, it was
possible for the same person to h
31 matches
Mail list logo