Hi ,
If you are using single model you use single model with multiple fields .If
you are using multiple models you can use Foreign field to refer other
model in current model.(Player model)
On Wed, 1 Feb 2023, 20:33 datasci via Django users, <
django-users@googlegroups.com> wrote:
> I am designi
The best approach is for the Django/DB devs to create these fields (and
forms) in advance for the users to enter data.
If you want users to add "key/pair" type data which is not known in
advance, look to adding a JSON column to your table; see:
https://www.postgresql.org/docs/14/datatype-json.ht
Ohh you want create custom fields in forms
Take input, select, textarea tags, make them their own fields but save all
of these in fields in one table with types and max values all of the
attributes of tags
Finally show then what they chosen
On Sun, 23 Jan 2022 at 2:28 PM, Prashanth Patelc
wro
I would make the imports model an "intermediate model" - see here:
https://docs.djangoproject.com/en/1.6/topics/db/models/#extra-fields-on-many-to-many-relationships
L.
On 16 March 2014 09:41, willy Hakizimana wrote:
> Thank you guys so much. You guys rock!
>
>
> On Saturday, March 15, 2014 10:
Thank you guys so much. You guys rock!
On Saturday, March 15, 2014 10:38:03 AM UTC-5, willy Hakizimana wrote:
>
> First of all, this community is amazing at how fast questions are
> answered. I have learned so much.
>
>
> I am designing an app with models that look like this.
>
> Country(country_
Actually, the Django term for this is "through". Not via.
See
https://docs.djangoproject.com/en/1.6/topics/db/models/#extra-fields-on-many-to-many-relationships
on how to specify the intermediate table to be used in many-to-many
relationships.
Den lördagen den 15:e mars 2014 kl. 18:01:02 UTC
On Sat, Mar 15, 2014 at 9:38 AM, willy Hakizimana wrote:
> First of all, this community is amazing at how fast questions are answered.
> I have learned so much.
>
>
> I am designing an app with models that look like this.
>
> Country(country_id(PK), country_name, gdp, gdp_growth, income_per_capita
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
mart wrote:
>
> On Sep 30, 2009, at 4:17 PM, Thomas Guettler wrote:
>
>> In OrderDetail you have a ForeignKey to Product. But you need to
>> *copy*
>> the price. Example: if someone orders something at day1 for 1 dollar,
>> and you set the price on day2 to 3 dollar, you need to ship your
>>
On Sep 30, 2009, at 4:17 PM, Thomas Guettler wrote:
>
> In OrderDetail you have a ForeignKey to Product. But you need to
> *copy*
> the price. Example: if someone orders something at day1 for 1 dollar,
> and you set the price on day2 to 3 dollar, you need to ship your
> product cheap for all w
In OrderDetail you have a ForeignKey to Product. But you need to *copy*
the price. Example: if someone orders something at day1 for 1 dollar,
and you set the price on day2 to 3 dollar, you need to ship your
product cheap for all who odered before day2.
max kalinski wrote:
> hi djangos,
>
> i swi
On Sep 30, 2009, at 1:54 PM, Tim Chase wrote:
>
>> products_ordered = models.ManyToManyField(Product)
>>
>> i don't like it (as i would have to create my own "through" table/
>> class)
>> for saving the recent price, qty, date etc.
>
> I'm not sure what your complaint about the "through" table i
> products_ordered = models.ManyToManyField(Product)
>
> i don't like it (as i would have to create my own "through" table/
> class)
> for saving the recent price, qty, date etc.
I'm not sure what your complaint about the "through" table is --
is it that you'd have to create it (which you do be
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
Thanks for all of the suggestions. I will be checking those out.
On Nov 15, 2:25 am, Carl Holm <[EMAIL PROTECTED]> wrote:
> Another good read on the subject...
>
> Title: Database in Depth
> Subtitle: Relational Theory for Practitioners
> First Edition: May 2005
> Series: Theory In Practice
> ISB
Another good read on the subject...
Title: Database in Depth
Subtitle: Relational Theory for Practitioners
First Edition: May 2005
Series: Theory In Practice
ISBN: 0-596-10012-4
Pages: 228
- available from O'reilly
Eric Lake wrote:
> I think that I am really starting to understand how django wo
Data Modeling Essentials
by Graeme Simsion, Graham Witt
http://preview.tinyurl.com/yy6vlc
--~--~-~--~~~---~--~~
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@goo
On 11/14/06, Eric Lake <[EMAIL PROTECTED]> wrote:
> I think that I am really starting to understand how django works. The area
> that I am not very good at is designing the database model. Can you
> recommend a good tutorial or book that gets into how create logical,
> elegant, efficient databases
Hello Eric,
On Tue, Nov 14, 2006 at 11:37:47AM -0500, Eric Lake wrote:
> I think that I am really starting to understand how django works. The area
> that I am not very good at is designing the database model. Can you
> recommend a good tutorial or book that gets into how create logical,
> elegan
48 matches
Mail list logo
