Re: Component design question

[J. Pic]

Damnit, my port was wrong above, here goes, with list for content and
dict for attributes as arguments instead of using *args, **kwargs:


if not request.user.is_authenticated:
content.append(
Li(
[A([_('Log in')], dict(href=reverse('crudlfap:login')))],
dict(cls='no-padding'),
)
)
else:
content.append(Li([A(
[_('Log out')],
{
'class': 'waves-effect',
'data-noprefetch': 'true',
'href': reverse('crudlfap:logout'),
}
)], {'class': 'no-padding'}))

The good side is that this mistake does make it look like it's more
error-prone than relying on some magic with *args, **kwargs. By magic
i mean: constructor take all *args, each arg that is text or a
component goes in self.content, if an arg is an Event then it goes in
self.events, although kwargs['events'] might also be set to a list ...

Would you favor readability in user code over readability in
constructor of core class Component ?

Thanks in advance

-- 
∞

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAC6Op1-Hyt_nP2-kNxGyLK7T%2BSa%2BtjHqctWgKimwvw6Hbu1_%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Component design question

[J. Pic]

Better for perspective to port the first example in second syntax to compare:


if not request.user.is_authenticated:
content.append(
Li(
A([_('Log in')], dict(href=reverse('crudlfap:login'))),
dict(cls='no-padding'),
)
)
else:
content.append(Li(A(
[_('Log out')],
{
'class': 'waves-effect',
'data-noprefetch': 'true',
'href': reverse('crudlfap:logout'),
}
), {'class': 'no-padding'}))

I think I could get used to it, but I still feel like the first syntax
is nicer to use.

Looking forward to read your opinions on this !

Have a great day

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAC6Op19fRRybpkUxHYy2s7%3DncBq5OB1g0%2BH0f-_BHQbz6ENejA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Component design question

[J. Pic]

Hi all,

We're running some experiments replacing templates by Components
(which support channels based data-binding amongst other niceties) in
Python, i would like to run an opinion survey about two syntaxes
before moving on. Syntax 0 is what seems more "pythonic" but requires
a less strict call signature by cooking *args and **kwargs which adds
a little overhead, but in in my opinion more readable:



if not request.user.is_authenticated:
content.append(
Li(
A(_('Log in'), href=reverse('crudlfap:login')),
cls='no-padding',
)
)
else:
content.append(Li(A(
_('Log out'),
**{
'class': 'waves-effect',
'data-noprefetch': 'true',
'href': reverse('crudlfap:logout'),
}
), cls='no-padding'))

The other syntax works with a strict constructor signature, adding no
overhead and less complex but in my opinion less readable and
enjoyable:

content = [Ul([
Li([
A(
router_link_content,
{'class': 'collapsible-header waves-effect waves-teal'},
),
Div(
sublinks,
{'class': 'collapsible-body'}
)
], {
'class': self.active
})
], {
'class': 'collapsible collapsible-accordion'
})]

If you were in the position where you had to decide what syntax to
keep before moving on, how would you decide ?

Thanks in advance for your feedback

More context:
https://yourlabs.io/oss/crudlfap/commit/85cccdfef936d4303c1abde39238b7dbd688eee1
https://yourlabs.io/oss/ryzom/tree/ssr

-- 
∞

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAC6Op18HQyX0TiY9u1%3DtxsPFTE9E4GG9LsbVw6j2cvfwXXXObw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Celery/Redis Django 2.0 Design Question

[hunter.cur...@gmail.com]

I think you are on the right track. I am doing something similar with 
photos and gps tracks uploaded by users and the celery/redis combo makes it 
easy to run a compute intensive task without blocking the site.
I'm not sure if the celery-signals approach is strictly necessary, 
however.  I am following the architecture laid out in cookiecutter-django  
(using docker) where the 
celery container is a copy of the django container.
That way, when the transformations are complete, the celery task can just 
issue a django style create or update command to access the database.

Good luck!
dave

On Saturday, October 27, 2018 at 6:13:19 PM UTC-6, mark wrote:
>
> I am building a django 2.x site to:
> * upload documents (images, pdfs, and videos)
> * apply metadata to the documents (JSON metadata field)
> * transform the documents (thumbnails, OCR, language translations, image 
> conversion, facial recognition, image blurring, etc.) based on some of the 
> metadata fields
> * display the documents
>
> Since the document transformations are fairly resource intensive and time 
> consuming, I am thinking of using celery to build a state machine for the 
> transformations, using celery tasks to transform the images, and celery 
> signals to update the state of the document as the transformations complete 
> successfully. I looked at django-fsm for this, but I think it will be 
> better to run the transformations as celery tasks than to block the site. 
>
> Does this plan make sense, or am I missing something regarding django and 
> celery/redis.
>
> Thanks!
>
> Mark
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/70a447cf-312a-42dd-9eaf-24db3ef238b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Celery/Redis Django 2.0 Design Question

[Mark Phillips]

I am building a django 2.x site to:
* upload documents (images, pdfs, and videos)
* apply metadata to the documents (JSON metadata field)
* transform the documents (thumbnails, OCR, language translations, image
conversion, facial recognition, image blurring, etc.) based on some of the
metadata fields
* display the documents

Since the document transformations are fairly resource intensive and time
consuming, I am thinking of using celery to build a state machine for the
transformations, using celery tasks to transform the images, and celery
signals to update the state of the document as the transformations complete
successfully. I looked at django-fsm for this, but I think it will be
better to run the transformations as celery tasks than to block the site.

Does this plan make sense, or am I missing something regarding django and
celery/redis.

Thanks!

Mark

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAEqej2NR0DfMyH1rZCaDpoxcJa7xzPb_inMJ3qbSFfc8U178KA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Model design question

[Mark Phillips]

On Sun, Jun 25, 2017 at 6:56 PM, Constantine Covtushenko <
constantine@gmail.com> wrote:

> Hi Mark,
>
> I have some questions to you.
> 1. Does any of MetaData have predefined list of MetaDataValues?
>

No, I want to add them in real time as Documents are uploaded.


> 2. Can MetaDataValue be assigned to many Documents or it is specific to
> particular Document?
>

Yes. For example, let's say there is a MetaData called People. The values
are Mary, John, and Fred. Document 1 can have MetaData People with values
Mary and John, Document 2 can have values Fred and Mary, Document 3 can
have values Mary, John, and Fred, and Document 4 may not have MetaData
People assigned to it.


> Regards,
> Constantine C.
>
> On Sun, Jun 25, 2017 at 6:20 PM, Mark Phillips  > wrote:
>
>> I have a class Document that uploads a document. I have a class MetaData
>> that is the name for some metadata for that document. Since a MetaData can
>> have one or more values, there is another class called MetaDataValue that
>> has a ForeignKey to MetaData. Finally, there is a class
>> DocumentMetaDataValue that links these three tables. It almost works...but
>> in the Admin screen when I want to add something to the DocumentMetaData
>> class I can select one or more documents from a drop down list (good!), and
>> one or more Metadata from a dropdown list (good), and I can select one or
>> more MetaDataValues from a drop down list (good). However, the bad news is
>> that the relationship between the MetaData and MetaDataValue is not
>> preserved.
>>
>> For example, say I have MetaData 'people' with values John, Mark,
>> Allison, and 'events' with values birthday, wedding, funeral. When I add a
>> DocumentMetaData, I want to select 'people' from the MetaData dropdown, and
>> then only the MetaDataValues for 'people' should be displayed in the
>> MetaDataValues dropdown. Instead, what I get is all the MetaDataValues
>> regardless of the associated MetaData, and I can add a MetaDataValue of
>> John to a document under the Metadata label of 'events'. What am I missing
>> in the relationship between the MetaDataValues class and the MetaData class?
>>
>> These are my classes. I have removed some of the extraneous fields and
>> methods in the classes for clarity.
>>
>> class MetaData(models.Model):
>> metadata_id = models.AutoField(primary_key = True)
>> name = models.CharField('metadata name', max_length=200)
>>
>> class MetaDataValue(models.Model):
>> metadata = models.ForeignKey(MetaData, on_delete=models.CASCADE,)
>> value = models.CharField('value', max_length=200)
>>
>> class Document(models.Model):
>> document_id = models.AutoField(primary_key=True)
>> title = models.CharField('title', max_length=200)
>>
>> class DocumentMetaData(models.Model):
>> document = models.ManyToManyField(Document)
>> metadata = models.ManyToManyField(MetaData)
>> metadatavalue = models.ManyToManyField(MetaDataValue)
>>
>> Thanks!
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-users+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-users@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-users.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/django-users/CAEqej2PO2bMW%2BZ%3DPJVy66%3DWspm6E7zetGrYH
>> yxjg-9iOjBmzaQ%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Sincerely yours,
> Constantine C
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-users/CAK52boVERbCZW1%3D0F7G_f%3DFyUtQtEBVeyuFkNQVpxs7%
> 3D91Gb3Q%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web 

Re: Model design question

[Constantine Covtushenko]

Hi Mark,

I have some questions to you.
1. Does any of MetaData have predefined list of MetaDataValues?
2. Can MetaDataValue be assigned to many Documents or it is specific to
particular Document?

Regards,
Constantine C.

On Sun, Jun 25, 2017 at 6:20 PM, Mark Phillips 
wrote:

> I have a class Document that uploads a document. I have a class MetaData
> that is the name for some metadata for that document. Since a MetaData can
> have one or more values, there is another class called MetaDataValue that
> has a ForeignKey to MetaData. Finally, there is a class
> DocumentMetaDataValue that links these three tables. It almost works...but
> in the Admin screen when I want to add something to the DocumentMetaData
> class I can select one or more documents from a drop down list (good!), and
> one or more Metadata from a dropdown list (good), and I can select one or
> more MetaDataValues from a drop down list (good). However, the bad news is
> that the relationship between the MetaData and MetaDataValue is not
> preserved.
>
> For example, say I have MetaData 'people' with values John, Mark, Allison,
> and 'events' with values birthday, wedding, funeral. When I add a
> DocumentMetaData, I want to select 'people' from the MetaData dropdown, and
> then only the MetaDataValues for 'people' should be displayed in the
> MetaDataValues dropdown. Instead, what I get is all the MetaDataValues
> regardless of the associated MetaData, and I can add a MetaDataValue of
> John to a document under the Metadata label of 'events'. What am I missing
> in the relationship between the MetaDataValues class and the MetaData class?
>
> These are my classes. I have removed some of the extraneous fields and
> methods in the classes for clarity.
>
> class MetaData(models.Model):
> metadata_id = models.AutoField(primary_key = True)
> name = models.CharField('metadata name', max_length=200)
>
> class MetaDataValue(models.Model):
> metadata = models.ForeignKey(MetaData, on_delete=models.CASCADE,)
> value = models.CharField('value', max_length=200)
>
> class Document(models.Model):
> document_id = models.AutoField(primary_key=True)
> title = models.CharField('title', max_length=200)
>
> class DocumentMetaData(models.Model):
> document = models.ManyToManyField(Document)
> metadata = models.ManyToManyField(MetaData)
> metadatavalue = models.ManyToManyField(MetaDataValue)
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-users/CAEqej2PO2bMW%2BZ%3DPJVy66%3DWspm6E7zetGrYHyxjg-
> 9iOjBmzaQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Sincerely yours,
Constantine C

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAK52boVERbCZW1%3D0F7G_f%3DFyUtQtEBVeyuFkNQVpxs7%3D91Gb3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Model design question

[Mark Phillips]

I have a class Document that uploads a document. I have a class MetaData
that is the name for some metadata for that document. Since a MetaData can
have one or more values, there is another class called MetaDataValue that
has a ForeignKey to MetaData. Finally, there is a class
DocumentMetaDataValue that links these three tables. It almost works...but
in the Admin screen when I want to add something to the DocumentMetaData
class I can select one or more documents from a drop down list (good!), and
one or more Metadata from a dropdown list (good), and I can select one or
more MetaDataValues from a drop down list (good). However, the bad news is
that the relationship between the MetaData and MetaDataValue is not
preserved.

For example, say I have MetaData 'people' with values John, Mark, Allison,
and 'events' with values birthday, wedding, funeral. When I add a
DocumentMetaData, I want to select 'people' from the MetaData dropdown, and
then only the MetaDataValues for 'people' should be displayed in the
MetaDataValues dropdown. Instead, what I get is all the MetaDataValues
regardless of the associated MetaData, and I can add a MetaDataValue of
John to a document under the Metadata label of 'events'. What am I missing
in the relationship between the MetaDataValues class and the MetaData class?

These are my classes. I have removed some of the extraneous fields and
methods in the classes for clarity.

class MetaData(models.Model):
metadata_id = models.AutoField(primary_key = True)
name = models.CharField('metadata name', max_length=200)

class MetaDataValue(models.Model):
metadata = models.ForeignKey(MetaData, on_delete=models.CASCADE,)
value = models.CharField('value', max_length=200)

class Document(models.Model):
document_id = models.AutoField(primary_key=True)
title = models.CharField('title', max_length=200)

class DocumentMetaData(models.Model):
document = models.ManyToManyField(Document)
metadata = models.ManyToManyField(MetaData)
metadatavalue = models.ManyToManyField(MetaDataValue)

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAEqej2PO2bMW%2BZ%3DPJVy66%3DWspm6E7zetGrYHyxjg-9iOjBmzaQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: DB Design question

[Javier Guerra Giraldez]

On Sat, Aug 1, 2015 at 4:53 AM, James Schneider  wrote:
> If you are talking about potentially having enough rows to extend past the
> AutoPK limits, you should consider instead using a UUID field as the PK:

note that this is only good advice if your DB handles it natively.  if
not, Django will use a charField to store it and constantly
encode-decode it.  If you're using PosgreSQL, then yes, UUID is great;
on MySQL, then it's far more efficient to use a BigInteger.  2^64
records still is far more than what you can store in the biggest
storage you can get.


-- 
Javier

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFkDaoRzx3m%2B4rYuppJw_hWtt552tVG769B67RuOj8EdJCrQsg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: DB Design question

[James Schneider]

If you are talking about potentially having enough rows to extend past the
AutoPK limits, you should consider instead using a UUID field as the PK:

https://docs.djangoproject.com/en/1.8/ref/models/fields/#uuidfield

The example in the docs uses UUID4. They index nicely and there are 2^128
(~3.4 x 10^38) UUID's available, the same as the total number of IPv6
addresses available. You'll run out of database resources (HDD, RAM, CPU)
and more importantly lifespan before running out of UUID's. I've seen some
larger DB applications use UUID's exclusively as their PK's for all tables.

Trying to merge fields to create uniqueness is difficult to do, wastes CPU,
can be buggy if fields are missing, etc., and probably doesn't index as
well.

If possible, I would also start thinking about a pruning/archiving strategy
to keep your main tables as lean as possible. With a couple billion rows,
you may see a bit of a stutter on queries. ;-D

-James


On Sat, Aug 1, 2015 at 1:56 AM, Stephen J. Butler 
wrote:

> Why not use a BigIntegerField?
>
> On Sat, Aug 1, 2015 at 12:06 AM, jordi collell  wrote:
>
>> Hi all!
>>
>> I have to store spreadsheet info on a db. Some kind of quotes where the
>> user can store distinct prices for every zone.
>>
>> After modeling the data, i have a Cell like row. (related to a zone, and
>> with a quantity field).. something like:
>>
>> zone1  1  100
>> zone1  2  99
>> zone1  3  98
>>
>> Every zone is a fk... The problem is, that data grows quick.. because
>> some quotes can have up to 65 unit fields with 70 to 100 zones..
>>
>> Currently i have a autopk field. but I'm not sure if it will scale.. If i
>> have 5000 users and every users makes 100 quotations.. (7000 rows on the
>> worst case) this is 35.. easy enought to get out of autoincrement
>> fields..
>>
>> I'm thinking on getting rid of the pk field, and use a unique together
>> with (zone_units). do you think this is a good aproach with the orm? I saw
>> that is not possible to make primary key fields ( with grouped fields), but
>> perhaps I can do it with instead of declaring a int field, have a char
>> field storing the
>> %s_%s_%s ( quote_id, zone_id, units ) ...
>>
>> do you think the last could be a good aproach?
>>
>> Sure if i have to shard the data (on the future) I can do it, using this
>> kind of keys.. Data will be queryed by zone.. (For making comparasions of
>> quotes)
>>
>> I will apreciate any help on the matter.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-users+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-users@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/c2a69c66-d1b8-4f08-95ed-b26fbb1d762e%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAD4ANxW3K2eA1pQ2L%3DZ3kJyooTjhpL1t6OzFF0r7KSY8Rvz5bQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2Be%2BciVJnqd5XUP%3DS4aLwC9hyB6a%3Du8iKZftU7-RB9cCsK5VAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: DB Design question

[Stephen J. Butler]

Why not use a BigIntegerField?

On Sat, Aug 1, 2015 at 12:06 AM, jordi collell  wrote:

> Hi all!
>
> I have to store spreadsheet info on a db. Some kind of quotes where the
> user can store distinct prices for every zone.
>
> After modeling the data, i have a Cell like row. (related to a zone, and
> with a quantity field).. something like:
>
> zone1  1  100
> zone1  2  99
> zone1  3  98
>
> Every zone is a fk... The problem is, that data grows quick.. because some
> quotes can have up to 65 unit fields with 70 to 100 zones..
>
> Currently i have a autopk field. but I'm not sure if it will scale.. If i
> have 5000 users and every users makes 100 quotations.. (7000 rows on the
> worst case) this is 35.. easy enought to get out of autoincrement
> fields..
>
> I'm thinking on getting rid of the pk field, and use a unique together
> with (zone_units). do you think this is a good aproach with the orm? I saw
> that is not possible to make primary key fields ( with grouped fields), but
> perhaps I can do it with instead of declaring a int field, have a char
> field storing the
> %s_%s_%s ( quote_id, zone_id, units ) ...
>
> do you think the last could be a good aproach?
>
> Sure if i have to shard the data (on the future) I can do it, using this
> kind of keys.. Data will be queryed by zone.. (For making comparasions of
> quotes)
>
> I will apreciate any help on the matter.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/c2a69c66-d1b8-4f08-95ed-b26fbb1d762e%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAD4ANxW3K2eA1pQ2L%3DZ3kJyooTjhpL1t6OzFF0r7KSY8Rvz5bQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

DB Design question

[jordi collell]

Hi all!

I have to store spreadsheet info on a db. Some kind of quotes where the 
user can store distinct prices for every zone. 

After modeling the data, i have a Cell like row. (related to a zone, and 
with a quantity field).. something like:

zone1  1  100
zone1  2  99
zone1  3  98

Every zone is a fk... The problem is, that data grows quick.. because some 
quotes can have up to 65 unit fields with 70 to 100 zones.. 

Currently i have a autopk field. but I'm not sure if it will scale.. If i 
have 5000 users and every users makes 100 quotations.. (7000 rows on the 
worst case) this is 35.. easy enought to get out of autoincrement 
fields.. 

I'm thinking on getting rid of the pk field, and use a unique together with 
(zone_units). do you think this is a good aproach with the orm? I saw that 
is not possible to make primary key fields ( with grouped fields), but 
perhaps I can do it with instead of declaring a int field, have a char 
field storing the 
%s_%s_%s ( quote_id, zone_id, units ) ... 

do you think the last could be a good aproach? 

Sure if i have to shard the data (on the future) I can do it, using this 
kind of keys.. Data will be queryed by zone.. (For making comparasions of 
quotes)

I will apreciate any help on the matter.


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/c2a69c66-d1b8-4f08-95ed-b26fbb1d762e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Design question: Is it really a good idea for models having “side effects”?

[Russell Keith-Magee]

On Fri, Feb 20, 2015 at 4:23 PM, Gergely Polonkai 
wrote:

> Hello,
>
> I’m currently implementing a finite state machine in my application using
> Django FSM[1]. In the Usage section of the README the author said that
> “This function may contain side-effects, like updating caches, notifying
> users, etc.”
>
> Opposing this statement, the Symfony PHP framework’s authors say that
> models should never have such side effects.
>
> Thus, I was wondering what is the case with Django in this topic. Should I
> really do such things, like notifying users, in the model’s code?
>

Separation of concerns isn't a Django thing or a Symfony thing - it's a
good software engineering thing.

I can't speak for the creators of Django FSM, but if I was to try an
interpret that statement, I'd say what they were trying to say is "this is
a place from which you can trigger other side effects", not "this is the
best place to put side effect logic".

It's a bit difficult to discuss without a concrete example, but I'd suggest
that the internal logic of your FSM isn't the best place to put complex
logic that touches external services (unless, of course, your FSM is
directly tied to managing that service). However, it *would* be appropriate
for your FSM to take the trigger of a state change, and use that as a
trigger for other system changes.

Put another way -  look at the process for testing your FSM. Will you be
able to test your FSM without a fully functional cache, notification
system, etc? If you're not able to configure your FSM in such a way that a
mock of your notification service can be passed in as a configuration
parameter, then you've probably coupled your FSM and your side effect logic
too closely. However, if you *can* drop in a testing mock as a
configuration item, you've captured the *type* of side effect that you
expect to occur, without tying it to a specific implementation.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAJxq849VE%3DJw7DjhTs%3DpRejWtb0q%3Dtab5YeVjbSDQHj%2BkvzuYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Design question: Is it really a good idea for models having “side effects”?

[Vijay Khemlani]

I'm not sure if there's an official stance on that, but I believe that
since Django is a "MVT" framework, that kind of logic does not seem to be
appropiate neither for templates nor views, so models seem like the logical
choice.

That way you can also make sure that the side-effect that you want to be
called (cache update when changing a model, for example) are always
executed when calling the model's method.

On Fri, Feb 20, 2015 at 5:23 AM, Gergely Polonkai 
wrote:

> Hello,
>
> I’m currently implementing a finite state machine in my application using
> Django FSM[1]. In the Usage section of the README the author said that
> “This function may contain side-effects, like updating caches, notifying
> users, etc.”
>
> Opposing this statement, the Symfony PHP framework’s authors say that
> models should never have such side effects.
>
> Thus, I was wondering what is the case with Django in this topic. Should I
> really do such things, like notifying users, in the model’s code?
>
> Best,
> Gergely
>
>
> [1] https://github.com/kmmbvnr/django-fsm
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/69272d49-de97-40a0-9682-430f28f38663%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CALn3ei0q2-i2JQpe9zTS90PxCt%2BRY7%2BVRQLFRZPg21Muy581zA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Design question: Is it really a good idea for models having “side effects”?

[Gergely Polonkai]

Hello,

I’m currently implementing a finite state machine in my application using 
Django FSM[1]. In the Usage section of the README the author said that 
“This function may contain side-effects, like updating caches, notifying 
users, etc.”

Opposing this statement, the Symfony PHP framework’s authors say that 
models should never have such side effects.

Thus, I was wondering what is the case with Django in this topic. Should I 
really do such things, like notifying users, in the model’s code?

Best,
Gergely


[1] https://github.com/kmmbvnr/django-fsm

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/69272d49-de97-40a0-9682-430f28f38663%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Overall Design Question

[Gabriel Abdalla]

Hi Alex,

I'm still new to Django and Python, but I have experience in other
frameworks. Here is my opinion regarding your three points:

*(1) An app for each role.* I think the approach of having one app for each
role is the worst thing to do. In this case, you would have too much
duplicated code and the maintenance would be difficult.

*(2) Some logic in templates.* If you have it in templates, you would be
putting logic in the Template tier of your application, which, in my point
of view, is architecturally wrong. You should separate Model, Template and
View (MTV).

*(3) Any other.* I believe the best approach is to define permissions for
each user role. I don't know how to implement it in a Django application
yet, but I'm quite sure this is the right thing to do. From the documents
I've read, it should be implemented in the View tier.

Please correct me if I'm wrong.

Regards,

Gabriel Abdalla


On 11 February 2013 13:30, Bill Freeman  wrote:

>
>
> On Mon, Feb 11, 2013 at 7:13 AM, Ajinkya Gadewar <
> ajinkya.gade...@ishareitall.com> wrote:
>
>> Hi Alex,
>>
>> I already have a education system developed. We run a software company in
>> India. Let me know if you need more details on it.
>>
>> Regards,
>> Ajinkya Gadewar
>>
>> Sent from my iPhone
>>
>> On 11-Feb-2013, at 2:17 PM, "alexandre...@gmail.com" <
>> alexandre...@gmail.com> wrote:
>>
>> Hi
>> I'm starting a big app on Django for Shool management, to replace a Win32
>> app.
>>
>> I've roles like teachers, students, admin stuff, ... that have diferent
>> access.
>> How should it be developded?
>>
>> 1- an app for each role?
>> 2- some logic in templates?
>> 3- any other
>>
>> what is the correct aporach to get big and simple.
>>
>> Regards
>> Alex
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-users+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-users@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-users?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>>
>> An app for each role would seem to lead to a lot of code duplication.  I
> think that permissions are best implemented at the view level (and
> templates can be taken to be part of the view).  While you should restrict
> some views entirely by role, you will also want some template code, so that
> links to those views won't display for those whose role can't access them
> (though you could also hide unusable links with css and a roll based class
> on the body element).  There may also be views that should be read only for
> some roles and a form for others (though I prefer the separate "edit this
> stuff" view approach).  Consider using the django permissions and group
> system for roles.
>
> Bill
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Overall Design Question

[Bill Freeman]

On Mon, Feb 11, 2013 at 7:13 AM, Ajinkya Gadewar <
ajinkya.gade...@ishareitall.com> wrote:

> Hi Alex,
>
> I already have a education system developed. We run a software company in
> India. Let me know if you need more details on it.
>
> Regards,
> Ajinkya Gadewar
>
> Sent from my iPhone
>
> On 11-Feb-2013, at 2:17 PM, "alexandre...@gmail.com" <
> alexandre...@gmail.com> wrote:
>
> Hi
> I'm starting a big app on Django for Shool management, to replace a Win32
> app.
>
> I've roles like teachers, students, admin stuff, ... that have diferent
> access.
> How should it be developded?
>
> 1- an app for each role?
> 2- some logic in templates?
> 3- any other
>
> what is the correct aporach to get big and simple.
>
> Regards
> Alex
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> An app for each role would seem to lead to a lot of code duplication.  I
think that permissions are best implemented at the view level (and
templates can be taken to be part of the view).  While you should restrict
some views entirely by role, you will also want some template code, so that
links to those views won't display for those whose role can't access them
(though you could also hide unusable links with css and a roll based class
on the body element).  There may also be views that should be read only for
some roles and a form for others (though I prefer the separate "edit this
stuff" view approach).  Consider using the django permissions and group
system for roles.

Bill

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Overall Design Question

[Ajinkya Gadewar]

Hi Alex,

I already have a education system developed. We run a software company in 
India. Let me know if you need more details on it.

Regards,
Ajinkya Gadewar

Sent from my iPhone

On 11-Feb-2013, at 2:17 PM, "alexandre...@gmail.com"  
wrote:

> Hi
> I'm starting a big app on Django for Shool management, to replace a Win32 app.
> 
> I've roles like teachers, students, admin stuff, ... that have diferent 
> access.
> How should it be developded?
> 
> 1- an app for each role?
> 2- some logic in templates?
> 3- any other
> 
> what is the correct aporach to get big and simple.
> 
> Regards
> Alex
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Overall Design Question

[alexandre...@gmail.com]

Hi
I'm starting a big app on Django for Shool management, to replace a Win32 
app.

I've roles like teachers, students, admin stuff, ... that have diferent 
access.
How should it be developded?

1- an app for each role?
2- some logic in templates?
3- any other

what is the correct aporach to get big and simple.

Regards
Alex

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Model design question

[oneroler]

Mike, Anssi,

Thank you for your replies.  I will give this a shot and see if I can get 
it to work.

Sam

On Thursday, May 17, 2012 9:59:40 PM UTC-7, akaariai wrote:
>
> On May 18, 5:25 am, oneroler  wrote: 
> > Thanks Mike, that is what I was originally planning to do but realized 
> > there would be situations where that wouldn't do exactly what I wanted. 
> > For example, if there is a business that only has the strategy 
> 'wholesale' 
> > assigned, using ForeignKey would still allow me to assign a different 
> > strategy to a division.  I was hoping to find a solution where the 
> strategy 
> > for a division is constrained by the strategies assigned to its 
> respective 
> > business. 
>
> Django doesn't make this particularly easy. You should create the 
> constraint in the database by using custom SQL, and then constraint 
> the assignable objects in Python in your view code. The Strategy and 
> Business models will create three tables into the database, one of the 
> tables is the many-to-many table. The m2m table's structure should be 
> something like this (check manage.py sqlall output): 
>
> create table business_strategy( 
> id serial primary key, 
> business_id integer references strategy(id), 
> strategy id integer references business(id), 
> unique (business_id, strategy_id) 
> ) 
>
> Now, what you need to do is create a foreign key pointing to 
> business_id, strategy_id for your division table. The model should 
> look like this: 
>
> class Division(models.Model): 
> business = models.ForeignKey(Business) 
> name = models.CharField() 
> strategy = models.ForeignKey(Strategy) 
>
> this creates a table ( 
>  id serial primary key, 
>  business_id integer references business(id), 
>  name varchar(n), 
>  strategy_id integer references strategy(id), 
> ) 
>
> You will need to drop the strategy_id -> strategy(id) foreign key by 
> hand and add a new one: business_id, strategy_id -> 
> business_strategy(business_id, strategy_id). Check your database 
> vendors docs for details how to do this. You will want this constraint 
> to be deferred if available on your DB. 
>
> So, now you should have correct constraint in the database. You will 
> still have some problems: changing division's business changes the set 
> of available strategies. On UI side you will probably need to create 
> an AJAX call on business changed to fetch the available strategies. In 
> forms code you will need to do something like this: 
>
> class DivisionForm(forms.ModelForm): 
> class Meta: 
>   model = Division 
> def __init__(self, **kwargs): 
>   # Note, intentionally restrict the forms usage to only 
> kwargs. 
>   super(DivisionForm, self).__init__(**kwargs) 
>   business_id = None 
>   if 'initial' in kwargs: 
>   business_id = kwargs['initial'].business_id 
>   if 'data' in kwargs and 'business_id' in kwargs['data']: 
>   business_id = kwargs['data']['business_id'] 
>   self.fields['strategy'].queryset = 
> Strategy.objects.filter(business_set=business_id) 
>
> So, the restriction should be doable both in DB and Django, but isn't 
> trivial to do. The above is pseudo-code style, so the example code 
> will likely not work by copy-pasting... 
>
>  - Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/JdPApZhO6x8J.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Model design question

[akaariai]

On May 18, 5:25 am, oneroler  wrote:
> Thanks Mike, that is what I was originally planning to do but realized
> there would be situations where that wouldn't do exactly what I wanted.
> For example, if there is a business that only has the strategy 'wholesale'
> assigned, using ForeignKey would still allow me to assign a different
> strategy to a division.  I was hoping to find a solution where the strategy
> for a division is constrained by the strategies assigned to its respective
> business.

Django doesn't make this particularly easy. You should create the
constraint in the database by using custom SQL, and then constraint
the assignable objects in Python in your view code. The Strategy and
Business models will create three tables into the database, one of the
tables is the many-to-many table. The m2m table's structure should be
something like this (check manage.py sqlall output):

create table business_strategy(
id serial primary key,
business_id integer references strategy(id),
strategy id integer references business(id),
unique (business_id, strategy_id)
)

Now, what you need to do is create a foreign key pointing to
business_id, strategy_id for your division table. The model should
look like this:

class Division(models.Model):
business = models.ForeignKey(Business)
name = models.CharField()
strategy = models.ForeignKey(Strategy)

this creates a table (
 id serial primary key,
 business_id integer references business(id),
 name varchar(n),
 strategy_id integer references strategy(id),
)

You will need to drop the strategy_id -> strategy(id) foreign key by
hand and add a new one: business_id, strategy_id ->
business_strategy(business_id, strategy_id). Check your database
vendors docs for details how to do this. You will want this constraint
to be deferred if available on your DB.

So, now you should have correct constraint in the database. You will
still have some problems: changing division's business changes the set
of available strategies. On UI side you will probably need to create
an AJAX call on business changed to fetch the available strategies. In
forms code you will need to do something like this:

class DivisionForm(forms.ModelForm):
class Meta:
  model = Division
def __init__(self, **kwargs):
  # Note, intentionally restrict the forms usage to only
kwargs.
  super(DivisionForm, self).__init__(**kwargs)
  business_id = None
  if 'initial' in kwargs:
  business_id = kwargs['initial'].business_id
  if 'data' in kwargs and 'business_id' in kwargs['data']:
  business_id = kwargs['data']['business_id']
  self.fields['strategy'].queryset =
Strategy.objects.filter(business_set=business_id)

So, the restriction should be doable both in DB and Django, but isn't
trivial to do. The above is pseudo-code style, so the example code
will likely not work by copy-pasting...

 - Anssi

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Model design question

[Mike Dewhirst]

On 18/05/2012 12:25pm, oneroler wrote:
Thanks Mike, that is what I was originally planning to do but realized 
there would be situations where that wouldn't do exactly what I 
wanted.  For example, if there is a business that only has the 
strategy 'wholesale' assigned, using ForeignKey would still allow me 
to assign a different strategy to a division.  I was hoping to find a 
solution where the strategy for a division is constrained by the 
strategies assigned to its respective business.


It is done in the Admin by nesting admin.StackedInline classes. 
Essentially a queryset provides the choices for selecting a Strategy 
from those belonging to the Division's parent Business. Perhaps that is 
the way to do it in your forms.


To prevent incorrect Strategy assignment, I would build a 
Division.clean() method which tests whether the Division.strategy is valid.


I'm a beginner at this but here is a stab at a Division.clean() and 
maybe a dguru can contribute ...


Bear in mind that there will be an automatically created 
business_strategy table to carry all the many-to-many relationships. I 
would replace it with my own called (say) BusinessStrategy and in the 
Business model use the 'through' attribute to specify that table.


class BusinessStrategy(models.Model):
business = models.ForeignKey(Business)
strategy = models.ForeignKey(Strategy)

Then I could make a Division.clean() method something like this ...

def clean(self):
for item in BusinessStrategy.objects.all(business=self.business):
if self.strategy == item.strategy:
return True
raise ValidationError(u'Invalid strategy)




On Thursday, May 17, 2012 5:55:11 PM UTC-7, Mike Dewhirst wrote:

On 18/05/2012 7:02am, oneroler wrote:
> I'm trying to setup my first app and I'm trying to figure out
the best
> way to have constraints on a particular field (strategy for class
> Division noted below).  Below is the basic model structure.  What I
> would like is for the strategy under a Division to be
constrained to
> the strategies selected for the Business.  A business may have many
> strategies, but a division will only have one (but it should
only be
> one selected for the business).  Any help on this would be
> appreciated.  Thanks, Sam
>
> class Strategy(models.Model):
> name = models.CharField(max_length=200)
>
> #name would be something like retail, wholesale, etc
>
> class Business(models.Model):
>name = models.CharField()
>strategy = models.ManyToManyField(Strategy)
>
> class Division(models.Model):
> business = models.ForeignKey(Business)
> name = models.CharField()
> strategy = ???

Try ...

strategy = models.ForeignKey(Strategy)


>
> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/sunwQb8Ft0cJ
.
> To post to this group, send email to
django-users@googlegroups.com .
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com
.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en
.

--
You received this message because you are subscribed to the Google 
Groups "Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/-hITt8lS1f0J.

To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.


--
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Model design question

[oneroler]

Thanks Mike, that is what I was originally planning to do but realized 
there would be situations where that wouldn't do exactly what I wanted.  
For example, if there is a business that only has the strategy 'wholesale' 
assigned, using ForeignKey would still allow me to assign a different 
strategy to a division.  I was hoping to find a solution where the strategy 
for a division is constrained by the strategies assigned to its respective 
business.

On Thursday, May 17, 2012 5:55:11 PM UTC-7, Mike Dewhirst wrote:
>
> On 18/05/2012 7:02am, oneroler wrote: 
> > I'm trying to setup my first app and I'm trying to figure out the best 
> > way to have constraints on a particular field (strategy for class 
> > Division noted below).  Below is the basic model structure.  What I 
> > would like is for the strategy under a Division to be constrained to 
> > the strategies selected for the Business.  A business may have many 
> > strategies, but a division will only have one (but it should only be 
> > one selected for the business).  Any help on this would be 
> > appreciated.  Thanks, Sam 
> > 
> > class Strategy(models.Model): 
> > name = models.CharField(max_length=200) 
> > 
> > #name would be something like retail, wholesale, etc 
> > 
> > class Business(models.Model): 
> >name = models.CharField() 
> >strategy = models.ManyToManyField(Strategy) 
> > 
> > class Division(models.Model): 
> > business = models.ForeignKey(Business) 
> > name = models.CharField() 
> > strategy = ??? 
>
> Try ... 
>
> strategy = models.ForeignKey(Strategy) 
>
>
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Django users" group. 
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msg/django-users/-/sunwQb8Ft0cJ. 
> > To post to this group, send email to django-users@googlegroups.com. 
> > To unsubscribe from this group, send email to 
> > django-users+unsubscr...@googlegroups.com. 
> > For more options, visit this group at 
> > http://groups.google.com/group/django-users?hl=en. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/-hITt8lS1f0J.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Model design question

[Mike Dewhirst]

On 18/05/2012 7:02am, oneroler wrote:
I'm trying to setup my first app and I'm trying to figure out the best 
way to have constraints on a particular field (strategy for class 
Division noted below).  Below is the basic model structure.  What I 
would like is for the strategy under a Division to be constrained to 
the strategies selected for the Business.  A business may have many 
strategies, but a division will only have one (but it should only be 
one selected for the business).  Any help on this would be 
appreciated.  Thanks, Sam


class Strategy(models.Model):
name = models.CharField(max_length=200)

#name would be something like retail, wholesale, etc

class Business(models.Model):
   name = models.CharField()
   strategy = models.ManyToManyField(Strategy)

class Division(models.Model):
business = models.ForeignKey(Business)
name = models.CharField()
strategy = ???


Try ...

   strategy = models.ForeignKey(Strategy)




--
You received this message because you are subscribed to the Google 
Groups "Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/sunwQb8Ft0cJ.

To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.


--
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Model design question

[oneroler]

I'm trying to setup my first app and I'm trying to figure out the best way 
to have constraints on a particular field (strategy for class Division 
noted below).  Below is the basic model structure.  What I would like is 
for the strategy under a Division to be constrained to the strategies 
selected for the Business.  A business may have many strategies, but a 
division will only have one (but it should only be one selected for the 
business).  Any help on this would be appreciated.  Thanks, Sam

class Strategy(models.Model):
name = models.CharField(max_length=200)

#name would be something like retail, wholesale, etc

class Business(models.Model):
   name = models.CharField()
   strategy = models.ManyToManyField(Strategy)

class Division(models.Model):
business = models.ForeignKey(Business) 
name = models.CharField()
strategy = ???

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/sunwQb8Ft0cJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Project general design question - "From scratch" or use of admin interface

[Andre Terra]

django-registration [1], quite possibly with a custom backend.


Cheers,
AT

[1] https://github.com/nathanborror/django-registration

On Mon, Nov 7, 2011 at 11:50 AM, youpsla <youp...@gmail.com> wrote:

> Ok,
> thanks for the answer,then I'll start this way.
>
> Just another question. I'll use a registration package I think for
> Shops owners, do you know wich one could be the best for jsut a simple
> registration workflow ?
>
>
> Agian, thnaks for your time
>
> Regards
>
> Alain
>
> On 7 nov, 13:32, Russell Keith-Magee <russ...@keith-magee.com> wrote:
> > On Mon, Nov 7, 2011 at 8:06 PM, youpsla <youp...@gmail.com> wrote:
> > > Hi,
> > > before getting more in depth in writing my project I ask you a general
> > > design question. My Django knowledge is not BIG enough for me to be
> > > able to have a clear answer (with for and cons) on my question.
> >
> > > Here are the main guidelines of my project :
> > > - I've two kind of users : Shop owners and consumers (I've already don
> > > the part for consumers wich is quite simple)
> > > - Shop owners have to register (Simple workflow : Email send with a
> > > link for confirmation and activation)
> > > - I like shops owners to be able to:
> > >- Create one ore more shops with some informations (Adress, openg/
> > > closing time etc )
> > >- For each shop, they can add events
> > >- Of course each shops owner can only access to shops and events
> > > he has created himself
> >
> > > My question, is:
> > > Do you thing it's better to use and customize the admin interface or
> > > it's better to write all "from scratch".
> >
> > Generally speaking, you're going to want to do it "from scratch".
> >
> > The admin interface isn't intended to be a framework for building your
> > site. It's exactly what it says on the box -- an administration
> > interface. It presents a very low-level view of your database, which
> > is handy for tweaking data at a low level, but it isn't really suited
> > to public facing sites.
> >
> > If you have requirements that involve customized workflows, or you're
> > expecting to customize views or structure, you're going to be better
> > served by building the site from scratch.
> >
> > That said, Django doesn't leave you completely to your own devices.
> > Most websites have, at their core, lots of fairly common functionality
> > -- show me a list of all available X objects; show me the details for
> > widget 3; allow me to edit the details for widget 3, and so on.
> >
> > This is where Django's generic views come in. The generic views are
> > pre-canned views for displaying and editing objects in common ways. If
> > you're looking to bang out a proof of concept, you'd be much better
> > suited to spending your time working out how to use generic views,
> > rather than trying to work out how to bend the admin to your will.
> >
> > Yours,
> > Russ Magee %-)
>
> --
> 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
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Project general design question - "From scratch" or use of admin interface

[youpsla]

Ok,
thanks for the answer,then I'll start this way.

Just another question. I'll use a registration package I think for
Shops owners, do you know wich one could be the best for jsut a simple
registration workflow ?


Agian, thnaks for your time

Regards

Alain

On 7 nov, 13:32, Russell Keith-Magee <russ...@keith-magee.com> wrote:
> On Mon, Nov 7, 2011 at 8:06 PM, youpsla <youp...@gmail.com> wrote:
> > Hi,
> > before getting more in depth in writing my project I ask you a general
> > design question. My Django knowledge is not BIG enough for me to be
> > able to have a clear answer (with for and cons) on my question.
>
> > Here are the main guidelines of my project :
> > - I've two kind of users : Shop owners and consumers (I've already don
> > the part for consumers wich is quite simple)
> > - Shop owners have to register (Simple workflow : Email send with a
> > link for confirmation and activation)
> > - I like shops owners to be able to:
> >    - Create one ore more shops with some informations (Adress, openg/
> > closing time etc )
> >    - For each shop, they can add events
> >    - Of course each shops owner can only access to shops and events
> > he has created himself
>
> > My question, is:
> > Do you thing it's better to use and customize the admin interface or
> > it's better to write all "from scratch".
>
> Generally speaking, you're going to want to do it "from scratch".
>
> The admin interface isn't intended to be a framework for building your
> site. It's exactly what it says on the box -- an administration
> interface. It presents a very low-level view of your database, which
> is handy for tweaking data at a low level, but it isn't really suited
> to public facing sites.
>
> If you have requirements that involve customized workflows, or you're
> expecting to customize views or structure, you're going to be better
> served by building the site from scratch.
>
> That said, Django doesn't leave you completely to your own devices.
> Most websites have, at their core, lots of fairly common functionality
> -- show me a list of all available X objects; show me the details for
> widget 3; allow me to edit the details for widget 3, and so on.
>
> This is where Django's generic views come in. The generic views are
> pre-canned views for displaying and editing objects in common ways. If
> you're looking to bang out a proof of concept, you'd be much better
> suited to spending your time working out how to use generic views,
> rather than trying to work out how to bend the admin to your will.
>
> Yours,
> Russ Magee %-)

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Project general design question - "From scratch" or use of admin interface

[Russell Keith-Magee]

On Mon, Nov 7, 2011 at 8:06 PM, youpsla <youp...@gmail.com> wrote:
> Hi,
> before getting more in depth in writing my project I ask you a general
> design question. My Django knowledge is not BIG enough for me to be
> able to have a clear answer (with for and cons) on my question.
>
> Here are the main guidelines of my project :
> - I've two kind of users : Shop owners and consumers (I've already don
> the part for consumers wich is quite simple)
> - Shop owners have to register (Simple workflow : Email send with a
> link for confirmation and activation)
> - I like shops owners to be able to:
>    - Create one ore more shops with some informations (Adress, openg/
> closing time etc )
>    - For each shop, they can add events
>    - Of course each shops owner can only access to shops and events
> he has created himself
>
> My question, is:
> Do you thing it's better to use and customize the admin interface or
> it's better to write all "from scratch".

Generally speaking, you're going to want to do it "from scratch".

The admin interface isn't intended to be a framework for building your
site. It's exactly what it says on the box -- an administration
interface. It presents a very low-level view of your database, which
is handy for tweaking data at a low level, but it isn't really suited
to public facing sites.

If you have requirements that involve customized workflows, or you're
expecting to customize views or structure, you're going to be better
served by building the site from scratch.

That said, Django doesn't leave you completely to your own devices.
Most websites have, at their core, lots of fairly common functionality
-- show me a list of all available X objects; show me the details for
widget 3; allow me to edit the details for widget 3, and so on.

This is where Django's generic views come in. The generic views are
pre-canned views for displaying and editing objects in common ways. If
you're looking to bang out a proof of concept, you'd be much better
suited to spending your time working out how to use generic views,
rather than trying to work out how to bend the admin to your will.

Yours,
Russ Magee %-)

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Project general design question - "From scratch" or use of admin interface

[youpsla]

Hi,
before getting more in depth in writing my project I ask you a general
design question. My Django knowledge is not BIG enough for me to be
able to have a clear answer (with for and cons) on my question.

Here are the main guidelines of my project :
- I've two kind of users : Shop owners and consumers (I've already don
the part for consumers wich is quite simple)
- Shop owners have to register (Simple workflow : Email send with a
link for confirmation and activation)
- I like shops owners to be able to:
- Create one ore more shops with some informations (Adress, openg/
closing time etc )
- For each shop, they can add events
- Of course each shops owner can only access to shops and events
he has created himself

My question, is:
Do you thing it's better to use and customize the admin interface or
it's better to write all "from scratch".

My goal here is to setup a POOF and not necessary is project wich can
handle millions of hits :-)


Feel free to ask further information if needed.

Thanks in advance for your time.


Alain

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Django models design question

[omerd]

Thank you very much!
I choose the first option for now.
If I have any problems, I will write them here

On Oct 17, 2:51 pm, Stuart  wrote:
> Hello Omer --
>
> I believe you have two options. You could use the AttributeValue
> approach I described earlier. You could add features to take care of
> 'data types' and the like. The work may be quite tedious, but it has
> the advantage of not being clever. In other words, you would do the
> work to implement each feature as you like, with no magic involved.
>
> The other approach is to extend django/python itself. Basically the
> approach here is what has been called dynamic models. You can google
> for it, but your best bet is probably this blog post and the pages it
> references.http://martyalchin.com/2007/aug/14/dynamic-models-in-real-world/
> However, note that the article is over four years old. You would no
> doubt have to update this approach for django 1.3. This approach would
> require knowledge of django/python extension points and likely some
> internals. It's probably the "better" approach assuming you are up for
> it. You would have to decide when to construct these dynamic models,
> among many other decisions.
>
> I'm on holiday for the next couple days, but I will check back with
> the list to see how you're getting on when I return.
>
> Good luck!
>
> --Stuart

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Django models design question

[Stuart]

Hello Omer --

I believe you have two options. You could use the AttributeValue
approach I described earlier. You could add features to take care of
'data types' and the like. The work may be quite tedious, but it has
the advantage of not being clever. In other words, you would do the
work to implement each feature as you like, with no magic involved.

The other approach is to extend django/python itself. Basically the
approach here is what has been called dynamic models. You can google
for it, but your best bet is probably this blog post and the pages it
references. http://martyalchin.com/2007/aug/14/dynamic-models-in-real-world/
However, note that the article is over four years old. You would no
doubt have to update this approach for django 1.3. This approach would
require knowledge of django/python extension points and likely some
internals. It's probably the "better" approach assuming you are up for
it. You would have to decide when to construct these dynamic models,
among many other decisions.

I'm on holiday for the next couple days, but I will check back with
the list to see how you're getting on when I return.


Good luck!

--Stuart

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Django models design question

[omerd]

I should also mention that one AttributeValue table for all the
registrations isn't good for my purpose, because it says that the
Value column must have a specific type field. I want that every detail
(Atrribute) will have the option to be from any field type
(CharField,DateTimeField, etc).

On Oct 15, 9:37 pm, omerd  wrote:
> Thank you for the response.
>
> As stuart wrote, i should give more details about the website.
> Currently let's suppose I have 2 interesting tables (I'm not sure that
> the relationship between these 2 tables is well designed):
>
> 1. Details, that contains all the possible information that should be
> provided to register for something.
> For example: first name, last name, phone number, address etc.
>
> I should mention again that every registration needs other set of
> details
>
> 2. Registration, that have the following columns:
> admin (the admin of the registration), registration_name,id , foreign
> key to Details(many to many).
>
> actually, I chose the first model that sturat described. I wan't that
> some users that have the appropriate privileges (super-user) will be
> able to define new registration for something. For example, let's
> suppose that a new user asks me to use the infrastructure of the
> website to create a new registration for his handgun shop because he
> wants to know the amount of arms that have to be taken from the
> factory.
> So, I, as the site admin, adding 2 new record to the Details table
> (caliber and shell capacity), and a new record to the registration
> table. This is very simple and can be done from the admin site.
>
> The problem is that I need to change the code (models.py) and add a
> new model called "Handgun"- a model for the registration that has
> those columns:
> Foreign key to Registration table, Shell capacity, Caliber Capacity.
>
> I don't want to change the code (models.py) whenever I'm adding a new
> registration record. this attitude is bad and not scalable.
>
> I'm need your advice!
>
> On Oct 14, 6:30 pm, Stuart  wrote:
>
>
>
>
>
>
>
> > Hello omerd --
>
> > If you give some concrete examples of what you are trying to do,
> > including providing your current models.py code, it will make it
> > easier for us to help you.
>
> > Since you have Registration and Details models, I am assuming you want
> > the user to be able to create/define these items, rather than
> > specifying them yourself beforehand. So if I am a user of your system,
> > I can define a new Registration for handguns, and indicate that I want
> > Details of caliber and shell capacity. Then another user can access
> > the system and register his .38 six-shooter. Is that the kind of thing
> > you have in mind? If so, you are essentially giving the users the
> > ability to define a new table (Registration) with certain columns
> > (Details), and then letting them populate it (and you would store the
> > actual values using another model like 'AttributeValue').
>
> > On the other hand, if you are defining the subjects beforehand as the
> > developer, you will want a different approach altogether. In that case
> > you might consider something like model inheritance (https://
> > docs.djangoproject.com/en/1.3/topics/db/models/#model-inheritance) or
> > some other technique to keep things DRY as you add dozens of
> > registration subjects.
>
> > Hope that helps,
>
> > --Stuart
>
> > On Oct 14, 6:53 am, omerd  wrote:
>
> > > Hello everybody,
> > > I am writing my first web application with Django.
>
> > > I want to create a web of registration for many subjects.
> > > However, each subject require different set of details to be supplied
> > > so I don't know which models should I have in the database.
>
> > > Currently I have two models:
> > > Registration - describes a registration (each record is a different
> > > subject)
> > > Details - describes all the possible details which may be necessary to
> > > register.
>
> > > Now, each Registration instance should contain a list of the necessary
> > > details, so i guess that Registration and Details are Many-To-Many
> > > connected.
>
> > > My question is - how the other model(s) which contains the actual
> > > details and a FK to Registration model should look like? I don't want
> > > to create a new model for each Registration record and place the
> > > necessary details hardcoded in the model fields. What if I have 30
> > > records in Registration table ?!

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Django models design question

[omerd]

Thank you for the response.

As stuart wrote, i should give more details about the website.
Currently let's suppose I have 2 interesting tables (I'm not sure that
the relationship between these 2 tables is well designed):

1. Details, that contains all the possible information that should be
provided to register for something.
For example: first name, last name, phone number, address etc.

I should mention again that every registration needs other set of
details

2. Registration, that have the following columns:
admin (the admin of the registration), registration_name,id , foreign
key to Details(many to many).

actually, I chose the first model that sturat described. I wan't that
some users that have the appropriate privileges (super-user) will be
able to define new registration for something. For example, let's
suppose that a new user asks me to use the infrastructure of the
website to create a new registration for his handgun shop because he
wants to know the amount of arms that have to be taken from the
factory.
So, I, as the site admin, adding 2 new record to the Details table
(caliber and shell capacity), and a new record to the registration
table. This is very simple and can be done from the admin site.

The problem is that I need to change the code (models.py) and add a
new model called "Handgun"- a model for the registration that has
those columns:
Foreign key to Registration table, Shell capacity, Caliber Capacity.

I don't want to change the code (models.py) whenever I'm adding a new
registration record. this attitude is bad and not scalable.

I'm need your advice!


On Oct 14, 6:30 pm, Stuart  wrote:
> Hello omerd --
>
> If you give some concrete examples of what you are trying to do,
> including providing your current models.py code, it will make it
> easier for us to help you.
>
> Since you have Registration and Details models, I am assuming you want
> the user to be able to create/define these items, rather than
> specifying them yourself beforehand. So if I am a user of your system,
> I can define a new Registration for handguns, and indicate that I want
> Details of caliber and shell capacity. Then another user can access
> the system and register his .38 six-shooter. Is that the kind of thing
> you have in mind? If so, you are essentially giving the users the
> ability to define a new table (Registration) with certain columns
> (Details), and then letting them populate it (and you would store the
> actual values using another model like 'AttributeValue').
>
> On the other hand, if you are defining the subjects beforehand as the
> developer, you will want a different approach altogether. In that case
> you might consider something like model inheritance (https://
> docs.djangoproject.com/en/1.3/topics/db/models/#model-inheritance) or
> some other technique to keep things DRY as you add dozens of
> registration subjects.
>
> Hope that helps,
>
> --Stuart
>
> On Oct 14, 6:53 am, omerd  wrote:
>
>
>
>
>
>
>
> > Hello everybody,
> > I am writing my first web application with Django.
>
> > I want to create a web of registration for many subjects.
> > However, each subject require different set of details to be supplied
> > so I don't know which models should I have in the database.
>
> > Currently I have two models:
> > Registration - describes a registration (each record is a different
> > subject)
> > Details - describes all the possible details which may be necessary to
> > register.
>
> > Now, each Registration instance should contain a list of the necessary
> > details, so i guess that Registration and Details are Many-To-Many
> > connected.
>
> > My question is - how the other model(s) which contains the actual
> > details and a FK to Registration model should look like? I don't want
> > to create a new model for each Registration record and place the
> > necessary details hardcoded in the model fields. What if I have 30
> > records in Registration table ?!

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Django models design question

[Stuart]

Hello omerd --

If you give some concrete examples of what you are trying to do,
including providing your current models.py code, it will make it
easier for us to help you.

Since you have Registration and Details models, I am assuming you want
the user to be able to create/define these items, rather than
specifying them yourself beforehand. So if I am a user of your system,
I can define a new Registration for handguns, and indicate that I want
Details of caliber and shell capacity. Then another user can access
the system and register his .38 six-shooter. Is that the kind of thing
you have in mind? If so, you are essentially giving the users the
ability to define a new table (Registration) with certain columns
(Details), and then letting them populate it (and you would store the
actual values using another model like 'AttributeValue').

On the other hand, if you are defining the subjects beforehand as the
developer, you will want a different approach altogether. In that case
you might consider something like model inheritance (https://
docs.djangoproject.com/en/1.3/topics/db/models/#model-inheritance) or
some other technique to keep things DRY as you add dozens of
registration subjects.


Hope that helps,

--Stuart

On Oct 14, 6:53 am, omerd  wrote:
> Hello everybody,
> I am writing my first web application with Django.
>
> I want to create a web of registration for many subjects.
> However, each subject require different set of details to be supplied
> so I don't know which models should I have in the database.
>
> Currently I have two models:
> Registration - describes a registration (each record is a different
> subject)
> Details - describes all the possible details which may be necessary to
> register.
>
> Now, each Registration instance should contain a list of the necessary
> details, so i guess that Registration and Details are Many-To-Many
> connected.
>
> My question is - how the other model(s) which contains the actual
> details and a FK to Registration model should look like? I don't want
> to create a new model for each Registration record and place the
> necessary details hardcoded in the model fields. What if I have 30
> records in Registration table ?!

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Django models design question

[omerd]

Hello everybody,
I am writing my first web application with Django.

I want to create a web of registration for many subjects.
However, each subject require different set of details to be supplied
so I don't know which models should I have in the database.

Currently I have two models:
Registration - describes a registration (each record is a different
subject)
Details - describes all the possible details which may be necessary to
register.

Now, each Registration instance should contain a list of the necessary
details, so i guess that Registration and Details are Many-To-Many
connected.

My question is - how the other model(s) which contains the actual
details and a FK to Registration model should look like? I don't want
to create a new model for each Registration record and place the
necessary details hardcoded in the model fields. What if I have 30
records in Registration table ?!

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Database Design Question

[nixlists]

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 the
contractproduct table.

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Database Design Question

[Marc Aymerich]

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):
>> > for c in Contract.objects.all():
>> > for cp in c.contractproduct_set.all():
>> > print c, cp.product, cp.rebate_pct
>> > --
>> > Jani Tiainen
>>
>> Thanks. This works but kind of confusing, and I am looking for an easy
>> way to find rebate_pct given contract and product ids.
>>
>
> Something like this?
>
> ContractProduct.objects.filter(contract__id=X,
> product__id=Y).values_list('rebate_pct', flat=True)
>
> or if you already have a contract:
> contract.products.filter(product__id=Y).values_list('rebate_pct',
> flat=True)
>
> or product:
> product.contractproduct_set.filter(contract__id=Y).values_list('rebate_pct',
> flat=True)
>

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)




-- 
Marc

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Database Design Question

[Marc Aymerich]

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.contractproduct_set.all():
> > print c, cp.product, cp.rebate_pct
> > --
> > Jani Tiainen
>
> Thanks. This works but kind of confusing, and I am looking for an easy
> way to find rebate_pct given contract and product ids.
>

Something like this?

ContractProduct.objects.filter(contract__id=X,
product__id=Y).values_list('rebate_pct', flat=True)

or if you already have a contract:
contract.products.filter(product__id=Y).values_list('rebate_pct', flat=True)

or product:
product.contractproduct_set.filter(contract__id=Y).values_list('rebate_pct',
flat=True)


-- 
Marc

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Database Design Question

[nixlists]

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
> --
> Jani Tiainen

Thanks. This works but kind of confusing, and I am looking for an easy
way to find rebate_pct given contract and product ids.

Thanks.

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Database Design Question

[Jani Tiainen]

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/topics/db/models/#intermediary-manytomany
> >
> > for more. So in the end your models would probably look a alike
> following:
> > class Contract():
> > contract_id = models.lIntegerField(...)
> > products = models.ManyToManyField(Product, through='ContractProduct')
> > class ContractProduct():
> > contract = models.ForeignKey(Contract)
> > product = models.ForeignKey(Product)
> > rebate_pct = models.DecimalField(max_digits=4, decimal_places=2)
> > So now you can link Contract with multiple Products adding custom
> rebate_pct
> > value to each link.
> > And what comes to rebate value, I think you want to keep value with
> product
> > linkage for two reasons:
> > 1) It's a single scalar value
> > 2) It's probably something that should not be changed ever after saving.
> > hth,
>
> Thanks for your response, I think this will work. How would I write a
> query to find the rebate_pct per contract per product?
>
>
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

-- 

Jani Tiainen

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Database Design Question

[nixlists]

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"
> 
> for more. So in the end your models would probably look a alike following:
> class Contract():
>     contract_id = models.lIntegerField(...)
>     products = models.ManyToManyField(Product, through='ContractProduct')
> class ContractProduct():
>     contract = models.ForeignKey(Contract)
>     product = models.ForeignKey(Product)
>     rebate_pct = models.DecimalField(max_digits=4, decimal_places=2)
> So now you can link Contract with multiple Products adding custom rebate_pct
> value to each link.
> And what comes to rebate value, I think you want to keep value with product
> linkage for two reasons:
> 1) It's a single scalar value
> 2) It's probably something that should not be changed ever after saving.
> hth,

Thanks for your response, I think this will work. How would I write a
query to find the rebate_pct per contract per product?

Thanks!

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Database Design Question

[Jani Tiainen]

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 Contract():
contract_id = models.lIntegerField(...)
products = models.ManyToManyField(Product, through='ContractProduct')

class ContractProduct():
contract = models.ForeignKey(Contract)
product = models.ForeignKey(Product)
rebate_pct = models.DecimalField(max_digits=4, decimal_places=2)

So now you can link Contract with multiple Products adding custom rebate_pct
value to each link.

And what comes to rebate value, I think you want to keep value with product
linkage for two reasons:
1) It's a single scalar value
2) It's probably something that should not be changed ever after saving.

hth,

-- 

Jani Tiainen

On Thu, Jul 21, 2011 at 8:25 PM, newtodjango  wrote:

> 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 django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Database Design Question

[newtodjango]

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 django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Database Design Question

[newtodjango]

Hi. I have a question about writing normalized models. I began writing
an app that has non-normalized tables, and would like to rewrite it
with a normalized design.

I have non-normalized legacy tables like this without foreign keys or
many-to-many relationships, which I would like to have.

Contract

 id contract_id   product_id rebate_pct
  1 1  1230.22
  2 1  1240.30

Note repeating contract_id above. Each contract may have a different
number of products associated with it
Each product in the Contract table in turn has its own rebate_pct.

Product

id   product   product_name quantity_per_p
product_description
1  123name1
20   some_desc1
2  124name2
20   some_desc2

I'd like to define the Product model such that it has the unique
contract_id per row, but each contract_id should have the associated
multiple products and their rebate percentages.

I started with:

class Contract(models.Model):
contract_id = models.IntegerField(unique=True)
product = models.ManyToManyField(Product)

but don't know about rebate_pct. Should it be a ManyToMany into a
special rebates table?

Thanks.

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Model design question

[Yarin miran]

Hello everyone I just started with django and was wondering how to do
the following behaivor in my models:

class Game(models.Model)
  characters_count = models.IntegerField(default=1) #basically i set
to a choice of 1-3

class Match(models.Model)
 video=models.ForeignKey(Game)
 p1char1 = models.ForeignKey(Character)
 p2char1 = models.ForeignKey(Character)
 p1char2 = models.ForeignKey(Character)
 p2char2 = models.ForeignKey(Character)
 p1char3 = models.ForeignKey(Character)
 p2char3 = models.ForeignKey(Character)
video contains the instance game which Match relies on.

I need to create a constraint that the Character selected is from the
given game and that the number of characters each player selects is
limited by game as well.

Should I perform this on the Save method? or can I set these
constraints some other way so the forms will be generated by the
models accordingly without doing it manually.

Will the limitation on the characters (by the game) can be done on the
definition of the model?

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: 2D map application: performance and design question

[Lars Ruoff]

Excellent advice!
With this I'm down to less than 0.02 secs for the 13x13 map rendering!

Regards,
Lars


On Nov 2, 9:45 pm, Knut Ivar Nesheim  wrote:
> I would suggest rewriting the loop in your template as a templatetag.
> Something like this
>
> @register.simple_tag
> def render_locations(locations):
>     html = u""" html %(x)s stuff %(y)s here %(link)s """
>     return '\n'.join([html % { 'x': loc.x, 'y': loc.y', 'link':
> loc.link } for loc in locations])
>
> I've used this approach a few times with good results for my use cases.
>
> Regards
> Knut
>
> On Tue, Nov 2, 2010 at 9:28 PM, Lars Ruoff  wrote:
> > Ok, thanks for the suggestion, Javier.
> > I implemented this and it showed:
> > I'm spending about
> > 0.2 secs for the queries,
> > but 1.5 secs for t.render(c) !
>
> > So rendering the template seems to take a significant amount of time!
> > As you can see, my template code iterates over about 13*13=169 objects
> > that have been passed in the context.
> > I then made tests to reduce this number. Here is the result of time
> > spent for the query and render() as a function of the grid size:
> > 3*3: 0.03s, 0.1s
> > 5*5: 0.04s, 0.25s
> > 7*7: 0.08s, 0.45s
> > 9*9: 0.13s, 0.72s
> > 11*11: 0.17s, 1.1s
> > 13*13: 0.2s, 1.5s
>
> > Lars
>
> > On Nov 2, 4:46 pm, Javier Guerra Giraldez  wrote:
> >> On Tue, Nov 2, 2010 at 3:35 AM, Lars Ruoff  wrote:
> >> > Ok, so having excluded SQLite and the static served files, I'd like to
> >> > test if the server matters. What would be a minimum Apache install and
> >> > config to run Django locally (on Windows)?
>
> >> again, that's _very_ unlikely to be the cause.  why not profile a
> >> little?  if you're not handy with a python profiler, just set a var
> >> 'starttime = datetime.now()' at the beginning of your view function
> >> and a few 'print(datetime.now() - starttime)' at strategic points.
>
> >> --
> >> Javier
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django users" group.
> > To post to this group, send email to django-us...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-users?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: 2D map application: performance and design question

[Knut Ivar Nesheim]

I would suggest rewriting the loop in your template as a templatetag.
Something like this

@register.simple_tag
def render_locations(locations):
html = u""" html %(x)s stuff %(y)s here %(link)s """
return '\n'.join([html % { 'x': loc.x, 'y': loc.y', 'link':
loc.link } for loc in locations])

I've used this approach a few times with good results for my use cases.

Regards
Knut

On Tue, Nov 2, 2010 at 9:28 PM, Lars Ruoff  wrote:
> Ok, thanks for the suggestion, Javier.
> I implemented this and it showed:
> I'm spending about
> 0.2 secs for the queries,
> but 1.5 secs for t.render(c) !
>
> So rendering the template seems to take a significant amount of time!
> As you can see, my template code iterates over about 13*13=169 objects
> that have been passed in the context.
> I then made tests to reduce this number. Here is the result of time
> spent for the query and render() as a function of the grid size:
> 3*3: 0.03s, 0.1s
> 5*5: 0.04s, 0.25s
> 7*7: 0.08s, 0.45s
> 9*9: 0.13s, 0.72s
> 11*11: 0.17s, 1.1s
> 13*13: 0.2s, 1.5s
>
> Lars
>
>
> On Nov 2, 4:46 pm, Javier Guerra Giraldez  wrote:
>> On Tue, Nov 2, 2010 at 3:35 AM, Lars Ruoff  wrote:
>> > Ok, so having excluded SQLite and the static served files, I'd like to
>> > test if the server matters. What would be a minimum Apache install and
>> > config to run Django locally (on Windows)?
>>
>> again, that's _very_ unlikely to be the cause.  why not profile a
>> little?  if you're not handy with a python profiler, just set a var
>> 'starttime = datetime.now()' at the beginning of your view function
>> and a few 'print(datetime.now() - starttime)' at strategic points.
>>
>> --
>> Javier
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: 2D map application: performance and design question

[Lars Ruoff]

Ok, thanks for the suggestion, Javier.
I implemented this and it showed:
I'm spending about
0.2 secs for the queries,
but 1.5 secs for t.render(c) !

So rendering the template seems to take a significant amount of time!
As you can see, my template code iterates over about 13*13=169 objects
that have been passed in the context.
I then made tests to reduce this number. Here is the result of time
spent for the query and render() as a function of the grid size:
3*3: 0.03s, 0.1s
5*5: 0.04s, 0.25s
7*7: 0.08s, 0.45s
9*9: 0.13s, 0.72s
11*11: 0.17s, 1.1s
13*13: 0.2s, 1.5s

Lars


On Nov 2, 4:46 pm, Javier Guerra Giraldez  wrote:
> On Tue, Nov 2, 2010 at 3:35 AM, Lars Ruoff  wrote:
> > Ok, so having excluded SQLite and the static served files, I'd like to
> > test if the server matters. What would be a minimum Apache install and
> > config to run Django locally (on Windows)?
>
> again, that's _very_ unlikely to be the cause.  why not profile a
> little?  if you're not handy with a python profiler, just set a var
> 'starttime = datetime.now()' at the beginning of your view function
> and a few 'print(datetime.now() - starttime)' at strategic points.
>
> --
> Javier

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: 2D map application: performance and design question

[Javier Guerra Giraldez]

On Tue, Nov 2, 2010 at 3:35 AM, Lars Ruoff  wrote:
> Ok, so having excluded SQLite and the static served files, I'd like to
> test if the server matters. What would be a minimum Apache install and
> config to run Django locally (on Windows)?

again, that's _very_ unlikely to be the cause.  why not profile a
little?  if you're not handy with a python profiler, just set a var
'starttime = datetime.now()' at the beginning of your view function
and a few 'print(datetime.now() - starttime)' at strategic points.

-- 
Javier

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: 2D map application: performance and design question

[Kenneth Gonsalves]

On Tue, 2010-11-02 at 01:35 -0700, Lars Ruoff wrote:
> Ok, so having excluded SQLite and the static served files, I'd like to
> test if the server matters. What would be a minimum Apache install and
> config to run Django locally (on Windows)? 

try nginx+fcgi/tornado/your favourite webserver
-- 
regards
Kenneth Gonsalves
Senior Associate
NRC-FOSS at AU-KBC

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: 2D map application: performance and design question

[Lars Ruoff]

Ok, so having excluded SQLite and the static served files, I'd like to
test if the server matters. What would be a minimum Apache install and
config to run Django locally (on Windows)?


On Nov 1, 7:30 pm, Lars Ruoff  wrote:
> Ok, thanks all,
>
> So following Bill's advice, i did:>python manage.py shell
> >>> import game.models
> >>> list(game.models.Location.objects.filter( \
>
> ...   x__gte=34, \
> ...   x__lte=46, \
> ...   y__gte=24, \
> ...   y__lte=36))
>
> ...and the result showed up instantly!
> So it seems DB is not the issue.
> Will do other testing...
>
> On Nov 1, 4:18 pm, Bill Freeman  wrote:
>
> > My experience with Django debug toolbar is that it makes things
> > slow all by itself.
>
> > I have done a couple of apps that use the equivalent query, using 
> > PostgreSQL,
> > without noticing a performance issue, with everything running on a Linux 
> > server.
>
> > 1. Have you tried timing the query by hand?  That is, run the manage.py 
> > shell,
> > import your model, and type a sample version of the query, wrapped in a 
> > list()
> > operation to force the query to evaluate right away.  If it's slow,
> > then you problem
> > is at least mostly in your DB/query choice.
>
> > 2. Is the machine in question tight on memory?  That could make things 
> > slower
> > that it would be on a production instance.
>
> > 3.  You might look at the "range" field lookup instead of pairs of
> > gte, lte.  I doubt
> > that it makes a performance difference, and I don't know if SQLite supports
> > BETWEEN, but it's easy to try.
>
> > 4. You show x and y as integers, but if that was just by way of example, and
> > they are really some complex (non-scalar) data type, the comparisons may not
> > be cheap on the database.
>
> > Bill
>
> > On Mon, Nov 1, 2010 at 8:13 AM, Javier Guerra Giraldez
>
> >  wrote:
> > > On Mon, Nov 1, 2010 at 5:55 AM, Cal Leeming [Simplicity Media Ltd]
> > >  wrote:
> > >> 9 out of 10 times, the bottleneck is usually the database
>
> > > true, but 8.7 of those 9 are about how the database is used, and not
> > > about the engine choice.  simply changing SQLite won't improve
> > > significantly the one-user case.
>
> > > the trick is: 1) get as few db queries as possible for each page.  2)
> > > use appropriate indices for those queries
>
> > > but first of all, you have to identify if it is really the DB where
> > > you're spending time.  the easiest way to be sure is to install
> > > django_debug_toolbar app, it's great to tell you exactly what's going
> > > on with the time and the DB accesses.
>
> > > --
> > > Javier
>
> > > --
> > > You received this message because you are subscribed to the Google Groups 
> > > "Django users" group.
> > > To post to this group, send email to django-us...@googlegroups.com.
> > > To unsubscribe from this group, send email to 
> > > django-users+unsubscr...@googlegroups.com.
> > > For more options, visit this group 
> > > athttp://groups.google.com/group/django-users?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: 2D map application: performance and design question

[Lars Ruoff]

Ok, thanks all,

So following Bill's advice, i did:
>python manage.py shell
>>> import game.models
>>> list(game.models.Location.objects.filter( \
...   x__gte=34, \
...   x__lte=46, \
...   y__gte=24, \
...   y__lte=36))

...and the result showed up instantly!
So it seems DB is not the issue.
Will do other testing...


On Nov 1, 4:18 pm, Bill Freeman  wrote:
> My experience with Django debug toolbar is that it makes things
> slow all by itself.
>
> I have done a couple of apps that use the equivalent query, using PostgreSQL,
> without noticing a performance issue, with everything running on a Linux 
> server.
>
> 1. Have you tried timing the query by hand?  That is, run the manage.py shell,
> import your model, and type a sample version of the query, wrapped in a list()
> operation to force the query to evaluate right away.  If it's slow,
> then you problem
> is at least mostly in your DB/query choice.
>
> 2. Is the machine in question tight on memory?  That could make things slower
> that it would be on a production instance.
>
> 3.  You might look at the "range" field lookup instead of pairs of
> gte, lte.  I doubt
> that it makes a performance difference, and I don't know if SQLite supports
> BETWEEN, but it's easy to try.
>
> 4. You show x and y as integers, but if that was just by way of example, and
> they are really some complex (non-scalar) data type, the comparisons may not
> be cheap on the database.
>
> Bill
>
> On Mon, Nov 1, 2010 at 8:13 AM, Javier Guerra Giraldez
>
>  wrote:
> > On Mon, Nov 1, 2010 at 5:55 AM, Cal Leeming [Simplicity Media Ltd]
> >  wrote:
> >> 9 out of 10 times, the bottleneck is usually the database
>
> > true, but 8.7 of those 9 are about how the database is used, and not
> > about the engine choice.  simply changing SQLite won't improve
> > significantly the one-user case.
>
> > the trick is: 1) get as few db queries as possible for each page.  2)
> > use appropriate indices for those queries
>
> > but first of all, you have to identify if it is really the DB where
> > you're spending time.  the easiest way to be sure is to install
> > django_debug_toolbar app, it's great to tell you exactly what's going
> > on with the time and the DB accesses.
>
> > --
> > Javier
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django users" group.
> > To post to this group, send email to django-us...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-users?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: 2D map application: performance and design question

[Bill Freeman]

My experience with Django debug toolbar is that it makes things
slow all by itself.

I have done a couple of apps that use the equivalent query, using PostgreSQL,
without noticing a performance issue, with everything running on a Linux server.

1. Have you tried timing the query by hand?  That is, run the manage.py shell,
import your model, and type a sample version of the query, wrapped in a list()
operation to force the query to evaluate right away.  If it's slow,
then you problem
is at least mostly in your DB/query choice.

2. Is the machine in question tight on memory?  That could make things slower
that it would be on a production instance.

3.  You might look at the "range" field lookup instead of pairs of
gte, lte.  I doubt
that it makes a performance difference, and I don't know if SQLite supports
BETWEEN, but it's easy to try.

4. You show x and y as integers, but if that was just by way of example, and
they are really some complex (non-scalar) data type, the comparisons may not
be cheap on the database.

Bill

On Mon, Nov 1, 2010 at 8:13 AM, Javier Guerra Giraldez
 wrote:
> On Mon, Nov 1, 2010 at 5:55 AM, Cal Leeming [Simplicity Media Ltd]
>  wrote:
>> 9 out of 10 times, the bottleneck is usually the database
>
> true, but 8.7 of those 9 are about how the database is used, and not
> about the engine choice.  simply changing SQLite won't improve
> significantly the one-user case.
>
> the trick is: 1) get as few db queries as possible for each page.  2)
> use appropriate indices for those queries
>
> but first of all, you have to identify if it is really the DB where
> you're spending time.  the easiest way to be sure is to install
> django_debug_toolbar app, it's great to tell you exactly what's going
> on with the time and the DB accesses.
>
> --
> Javier
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: 2D map application: performance and design question

[Javier Guerra Giraldez]

On Mon, Nov 1, 2010 at 5:55 AM, Cal Leeming [Simplicity Media Ltd]
 wrote:
> 9 out of 10 times, the bottleneck is usually the database

true, but 8.7 of those 9 are about how the database is used, and not
about the engine choice.  simply changing SQLite won't improve
significantly the one-user case.

the trick is: 1) get as few db queries as possible for each page.  2)
use appropriate indices for those queries

but first of all, you have to identify if it is really the DB where
you're spending time.  the easiest way to be sure is to install
django_debug_toolbar app, it's great to tell you exactly what's going
on with the time and the DB accesses.

-- 
Javier

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: 2D map application: performance and design question

[Lars Ruoff]

Hi Lukasz,
see my answer to Daniel. Replacing images by text didn't speed up
things much.
Is there any other test/profiling that i should do?
Would taking the systime before and after the query give me some
hints? I'll try this later...

On Nov 1, 12:39 pm, Łukasz Rekucki  wrote:
> On 1 November 2010 10:59, Lars Ruoff  wrote:
>
>
>
> > Hello,
>
> > first of all, these are my first steps with Django, and i only have
> > limited experience with Python, so please be patient.
>
> > I'm using it for what is intended to be a browser game in the future.
> > The main part of the game is a zoom view on a two-dimensional map of
> > fields.
>
> > I'm currently using Django 1.2.3 with Python 2.6 on Windows XP.
> > I'm using Python-provided SQLite and Django's local debug HTTP server
> > during development ('python manage.py runserver').
>
> > It works pretty well, but i notice that it takes several seconds to
> > update the map screen, which i consider unacceptable given the fact
> > that it runs locally.
>
> > I'm wondering where the performance bottleneck lies here.
> > Is it...
> > - SQLLite? (I.e. would switching to say PostgreSQL speed things up
> > considerably?)
>
> It could actually slow down things. Independently of the DB, you want
> to set up some indexes on your models (but I don't think that's your
> problem atm).
>
> > - Djangos debug web server? (I.e. would switching to apache speed
> > things up considerably?)
>
> Bingo! The development server is single-threaded and slow, so it
> totally sucks at serving *static files*. Looking at your template,
> your map is composed of many images and they all have to load
> sequentially via the devserver. Serving those images using Apache or
> Nginx should speed up things significantly.
>
> > - or the way my application is designed??
>
> In the long term, when the DB really starts to be your bottleneck, you
> want to do some research about all things "spatial" (like spatial
> indexes).
>
> --
> Łukasz Rekucki

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: 2D map application: performance and design question

[Łukasz Rekucki]

On 1 November 2010 10:59, Lars Ruoff  wrote:
> Hello,
>
> first of all, these are my first steps with Django, and i only have
> limited experience with Python, so please be patient.
>
> I'm using it for what is intended to be a browser game in the future.
> The main part of the game is a zoom view on a two-dimensional map of
> fields.
>
> I'm currently using Django 1.2.3 with Python 2.6 on Windows XP.
> I'm using Python-provided SQLite and Django's local debug HTTP server
> during development ('python manage.py runserver').
>
> It works pretty well, but i notice that it takes several seconds to
> update the map screen, which i consider unacceptable given the fact
> that it runs locally.
>
> I'm wondering where the performance bottleneck lies here.
> Is it...
> - SQLLite? (I.e. would switching to say PostgreSQL speed things up
> considerably?)

It could actually slow down things. Independently of the DB, you want
to set up some indexes on your models (but I don't think that's your
problem atm).

> - Djangos debug web server? (I.e. would switching to apache speed
> things up considerably?)

Bingo! The development server is single-threaded and slow, so it
totally sucks at serving *static files*. Looking at your template,
your map is composed of many images and they all have to load
sequentially via the devserver. Serving those images using Apache or
Nginx should speed up things significantly.

> - or the way my application is designed??

In the long term, when the DB really starts to be your bottleneck, you
want to do some research about all things "spatial" (like spatial
indexes).

-- 
Łukasz Rekucki

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: 2D map application: performance and design question

[Lars Ruoff]

Hi Daniel,

you are right that images are being loaded.
But i gave it a try and replaced the images by text.
Still the page takes about 3 seconds to load.

Lars


On Nov 1, 12:30 pm, Daniel Roseman  wrote:
> It's a bit hard to tell without knowing how the slowness appears. What
> exactly is slow?
>
> My instinct would be that it's simply a matter of image loading. Don't
> forget that the development server can only serve one thing at a time,
> so if you're loading a lot of images they are going to come up slowly.
> A dedicated server will be a lot better for that - might be worth
> experimenting with setting up Apache or Nginx or Lightppd just to
> serve the images for now, to see if that helps.
> --
> DR.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: 2D map application: performance and design question

[Lars Ruoff]

Ok, but that said, the database isn't that big here. (Well, i guess)
There are currently 4800 entries in the "Location" table.
Is this too much for SQLite already?

May it be the query in
locations = Location.objects.filter( \
x__gte=center_location.x-half_x, \
x__lte=center_location.x+half_x, \
y__gte=center_location.y-half_y, \
y__lte=center_location.y+half_y)
that might be non-optimal?

How to improve it?

Lars


On Nov 1, 11:55 am, "Cal Leeming [Simplicity Media Ltd]"
 wrote:
> Hi Lars,
>
> Unless you are doing some *really* intense Python code in your business
> logic, then 9 out of 10 times, the bottleneck is usually the database,
> especially if you are using Python.
>
> Cal

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: 2D map application: performance and design question

[Daniel Roseman]

On Nov 1, 9:59 am, Lars Ruoff  wrote:
> Hello,
>
> first of all, these are my first steps with Django, and i only have
> limited experience with Python, so please be patient.
>
> I'm using it for what is intended to be a browser game in the future.
> The main part of the game is a zoom view on a two-dimensional map of
> fields.
>
> I'm currently using Django 1.2.3 with Python 2.6 on Windows XP.
> I'm using Python-provided SQLite and Django's local debug HTTP server
> during development ('python manage.py runserver').
>
> It works pretty well, but i notice that it takes several seconds to
> update the map screen, which i consider unacceptable given the fact
> that it runs locally.
>
> I'm wondering where the performance bottleneck lies here.
> Is it...
> - SQLLite? (I.e. would switching to say PostgreSQL speed things up
> considerably?)
> - Djangos debug web server? (I.e. would switching to apache speed
> things up considerably?)
> - or the way my application is designed??
>
> Since the latter is a very probable answer, here is the way it works
> in a nutshell:
>
> The model is something like:
> 
> class Terrain(models.Model):
>     image_file = models.CharField(max_length=80)
>
> class Location(models.Model):
>     x = models.IntegerField()
>     y = models.IntegerField()
>     terrain = models.ForeignKey(Terrain)
>
> The heart of the view goes like this:
> 
>     center_location = Location.objects.get(id=location_id)
>
>     ## how many fields on the map view in each direction
>     half_x = 6
>     half_y = 6
>
>     locations = Location.objects.filter( \
>         x__gte=center_location.x-half_x, \
>         x__lte=center_location.x+half_x, \
>         y__gte=center_location.y-half_y, \
>         y__lte=center_location.y+half_y)
>
>     locs = []
>     for l in locations:
>         loc_info = {'id': l.id, \
>             'x': l.x - center_location.x + half_x, \
>             'y': l.y - center_location.y + half_y, \
>             'img': l.terrain.image_file}
>         locs.append(loc_info)
>
>     c = Context({
>         'locs': locs,
>     })
>     return HttpResponse(t.render(c))
>
> And the main part of the template renders these items:
> 
> {% for l in locs %}
>  src="/images/{{l.img}}" />
> {% endfor %}
>
> Do you see any issues with this approach? Any paths to performance
> improvements?
> Since i'm at the beginning of this project i would like to avoid going
> the wrong way.
>
> best regards,
> Lars

It's a bit hard to tell without knowing how the slowness appears. What
exactly is slow?

My instinct would be that it's simply a matter of image loading. Don't
forget that the development server can only serve one thing at a time,
so if you're loading a lot of images they are going to come up slowly.
A dedicated server will be a lot better for that - might be worth
experimenting with setting up Apache or Nginx or Lightppd just to
serve the images for now, to see if that helps.
--
DR.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: 2D map application: performance and design question

[Cal Leeming [Simplicity Media Ltd]]

Hi Lars,

Unless you are doing some *really* intense Python code in your business
logic, then 9 out of 10 times, the bottleneck is usually the database,
especially if you are using Python.

Cal


On Mon, Nov 1, 2010 at 9:59 AM, Lars Ruoff  wrote:

> Hello,
>
> first of all, these are my first steps with Django, and i only have
> limited experience with Python, so please be patient.
>
> I'm using it for what is intended to be a browser game in the future.
> The main part of the game is a zoom view on a two-dimensional map of
> fields.
>
> I'm currently using Django 1.2.3 with Python 2.6 on Windows XP.
> I'm using Python-provided SQLite and Django's local debug HTTP server
> during development ('python manage.py runserver').
>
> It works pretty well, but i notice that it takes several seconds to
> update the map screen, which i consider unacceptable given the fact
> that it runs locally.
>
> I'm wondering where the performance bottleneck lies here.
> Is it...
> - SQLLite? (I.e. would switching to say PostgreSQL speed things up
> considerably?)
> - Djangos debug web server? (I.e. would switching to apache speed
> things up considerably?)
> - or the way my application is designed??
>
> Since the latter is a very probable answer, here is the way it works
> in a nutshell:
>
> The model is something like:
> 
> class Terrain(models.Model):
>image_file = models.CharField(max_length=80)
>
> class Location(models.Model):
>x = models.IntegerField()
>y = models.IntegerField()
>terrain = models.ForeignKey(Terrain)
>
>
> The heart of the view goes like this:
> 
>center_location = Location.objects.get(id=location_id)
>
>## how many fields on the map view in each direction
>half_x = 6
>half_y = 6
>
>locations = Location.objects.filter( \
>x__gte=center_location.x-half_x, \
>x__lte=center_location.x+half_x, \
>y__gte=center_location.y-half_y, \
>y__lte=center_location.y+half_y)
>
>locs = []
>for l in locations:
>loc_info = {'id': l.id, \
>'x': l.x - center_location.x + half_x, \
>'y': l.y - center_location.y + half_y, \
>'img': l.terrain.image_file}
>locs.append(loc_info)
>
>c = Context({
>'locs': locs,
>})
>return HttpResponse(t.render(c))
>
>
> And the main part of the template renders these items:
> 
> {% for l in locs %}
>  src="/images/{{l.img}}" />
> {% endfor %}
>
>
> Do you see any issues with this approach? Any paths to performance
> improvements?
> Since i'm at the beginning of this project i would like to avoid going
> the wrong way.
>
> best regards,
> Lars
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>


-- 

Cal Leeming

Operational Security & Support Team

*Out of Hours: *+44 (07534) 971120 | *Support Tickets: *
supp...@simplicitymedialtd.co.uk
*Fax: *+44 (02476) 578987 | *Email: *cal.leem...@simplicitymedialtd.co.uk
*IM: *AIM / ICQ / MSN / Skype (available upon request)
Simplicity Media Ltd. All rights reserved.
Registered company number 7143564

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

2D map application: performance and design question

[Lars Ruoff]

Hello,

first of all, these are my first steps with Django, and i only have
limited experience with Python, so please be patient.

I'm using it for what is intended to be a browser game in the future.
The main part of the game is a zoom view on a two-dimensional map of
fields.

I'm currently using Django 1.2.3 with Python 2.6 on Windows XP.
I'm using Python-provided SQLite and Django's local debug HTTP server
during development ('python manage.py runserver').

It works pretty well, but i notice that it takes several seconds to
update the map screen, which i consider unacceptable given the fact
that it runs locally.

I'm wondering where the performance bottleneck lies here.
Is it...
- SQLLite? (I.e. would switching to say PostgreSQL speed things up
considerably?)
- Djangos debug web server? (I.e. would switching to apache speed
things up considerably?)
- or the way my application is designed??

Since the latter is a very probable answer, here is the way it works
in a nutshell:

The model is something like:

class Terrain(models.Model):
image_file = models.CharField(max_length=80)

class Location(models.Model):
x = models.IntegerField()
y = models.IntegerField()
terrain = models.ForeignKey(Terrain)


The heart of the view goes like this:

center_location = Location.objects.get(id=location_id)

## how many fields on the map view in each direction
half_x = 6
half_y = 6

locations = Location.objects.filter( \
x__gte=center_location.x-half_x, \
x__lte=center_location.x+half_x, \
y__gte=center_location.y-half_y, \
y__lte=center_location.y+half_y)

locs = []
for l in locations:
loc_info = {'id': l.id, \
'x': l.x - center_location.x + half_x, \
'y': l.y - center_location.y + half_y, \
'img': l.terrain.image_file}
locs.append(loc_info)

c = Context({
'locs': locs,
})
return HttpResponse(t.render(c))


And the main part of the template renders these items:

{% for l in locs %}

{% endfor %}


Do you see any issues with this approach? Any paths to performance
improvements?
Since i'm at the beginning of this project i would like to avoid going
the wrong way.

best regards,
Lars

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Database Design Question

[llanitedave]

Now that's a fascinating idea, because the three-table solution is
very similar to something I tried in the 1990's using a tool called
4th Dimension.  I've been out of database development for about a
decade, and this is my first foray into Django since doing the
tutorials.  The previous database had only a few sample types, and the
existing design limited our ability to expand.  The idea that you've
given here is pretty much the same one I came up with when trying to
find a way to expand its capabilities.  I never could get the
interface quite the way I wanted it using 4D, and the idea was never
implemented, but Django looks like it can give me a bit more
flexibility.  I hadn't thought of using a separate table for each
attribute data type, though.  That might be something to give a whirl
to.

Thanks, all!


On Jun 19, 1:52 am, S Basl <srb...@gmail.com> wrote:
> Ok.. that wasn't really ideal, a better (and more normalized) solution might
> look a bit like this:
>
> Sample Table:
> -> sample_id (pk)
> -> sample_type_id (fk)
> -> other descriptive fields
> Sample Type Table:
> -> sample_type_id (pk)
> -> other descriptive fields
>
> Attribute Type Table:
> -> attribute_type_id (pk)
> -> attribute_name
> -> attribute_datatype
>
> Attribute Tables:*
> ->attribute_id (pk)
> -> sample_id (fk)
> -> attribute_value
> *one attribute table for each appropriate datatype, ie string attribute
> table, integer attribute table, float attribute table, etc.
>
> With the above schema you should be able to allow users to define sample
> types, store those definitions in the database, and programattically create
> the necessary forms for any sample type necessary.
>
> On Sat, Jun 19, 2010 at 3:34 AM, <srb...@gmail.com> wrote:
> > I'm thinking you should be able to do this without having users create
> > tables. Three separate tables should be enough. Maybe more if you want to
> > get fancy.
>
> > Sample table: holds sample id & sample type (fk)
>
> > Sample type table: holds sample type id & comma separated list which
> > defines number and type of attributes for that type of sample.
>
> > Attribute table: holds attribute name, attribute value, and foreign key to
> > a sample id.
>
> > 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 <llanited...@veawb.coop>
> > Date: Fri, 18 Jun 2010 23:27:55
> > To: Django users<django-users@googlegroups.com>
> > 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 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 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 attributes.
>
> > For example, a fluid sample type might have the fields:  volume,
> > concentration, pH, and expiration date.
> > A soil sample might have the fields:  Clay content, color, grain size,
> > moisture content.
>
> > All sample types will have the common fields sample ID, sample type,
> > date collected, collector, source, and storage location.
>
> > So I'll need a generic "Sample" table and then related tables for each
> > sample type.
>
> > The difficulty is that many sample types are still undefined, and will
> > have to be defined by the individual users.  That means they'll have
> > to have an interface that allows them to create tables and fields in
> > the database.  I suppose I can put together a form for that which will
> > ensure it gets done in a limited, consistent and standard way.
>
> > I'm thinking out loud here, but it's getting the feedback that helped
> > to clarify it.  Any other comments or suggestions will be welcome.
>
> > On Jun 18, 9:46 pm, Venkatraman S <venka...@gmail.com> wrote:
> > > On Sat, Jun 19, 2010 at 10:12 AM, Venkatraman S <venka...@gmail.com>
> > 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, maint

Re: Database Design Question

[S Basl]

Ok.. that wasn't really ideal, a better (and more normalized) solution might
look a bit like this:

Sample Table:
-> sample_id (pk)
-> sample_type_id (fk)
-> other descriptive fields
Sample Type Table:
-> sample_type_id (pk)
-> other descriptive fields

Attribute Type Table:
-> attribute_type_id (pk)
-> attribute_name
-> attribute_datatype

Attribute Tables:*
->attribute_id (pk)
-> sample_id (fk)
-> attribute_value
*one attribute table for each appropriate datatype, ie string attribute
table, integer attribute table, float attribute table, etc.

With the above schema you should be able to allow users to define sample
types, store those definitions in the database, and programattically create
the necessary forms for any sample type necessary.

On Sat, Jun 19, 2010 at 3:34 AM, <srb...@gmail.com> wrote:

> I'm thinking you should be able to do this without having users create
> tables. Three separate tables should be enough. Maybe more if you want to
> get fancy.
>
> Sample table: holds sample id & sample type (fk)
>
> Sample type table: holds sample type id & comma separated list which
> defines number and type of attributes for that type of sample.
>
> Attribute table: holds attribute name, attribute value, and foreign key to
> a sample id.
>
> 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 <llanited...@veawb.coop>
> Date: Fri, 18 Jun 2010 23:27:55
> To: Django users<django-users@googlegroups.com>
> 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 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 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 attributes.
>
> For example, a fluid sample type might have the fields:  volume,
> concentration, pH, and expiration date.
> A soil sample might have the fields:  Clay content, color, grain size,
> moisture content.
>
> All sample types will have the common fields sample ID, sample type,
> date collected, collector, source, and storage location.
>
> So I'll need a generic "Sample" table and then related tables for each
> sample type.
>
> The difficulty is that many sample types are still undefined, and will
> have to be defined by the individual users.  That means they'll have
> to have an interface that allows them to create tables and fields in
> the database.  I suppose I can put together a form for that which will
> ensure it gets done in a limited, consistent and standard way.
>
> I'm thinking out loud here, but it's getting the feedback that helped
> to clarify it.  Any other comments or suggestions will be welcome.
>
> On Jun 18, 9:46 pm, Venkatraman S <venka...@gmail.com> wrote:
> > On Sat, Jun 19, 2010 at 10:12 AM, Venkatraman S <venka...@gmail.com>
> 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, i do not think that this table would contain a billion
> records
> > and even if it does, this design helps in sharding. Maintaining this
> system
> > in latter case would be more of a db-admin or sys-admin job - and already
> > there are many solutions in addition to sharding, when the size of a
> single
> > table is HUGE. (when Facebook can contain the entire 32Gb profile data in
> > the RAM, doesnt the world look small? ;)  )
> >
> > -V-http://twitter.com/venkasub
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Database Design Question

[srbasl]

I'm thinking you should be able to do this without having users create tables. 
Three separate tables should be enough. Maybe more if you want to get fancy.

Sample table: holds sample id & sample type (fk)

Sample type table: holds sample type id & comma separated list which defines 
number and type of attributes for that type of sample.

Attribute table: holds attribute name, attribute value, and foreign key to a 
sample id.

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 <llanited...@veawb.coop>
Date: Fri, 18 Jun 2010 23:27:55 
To: Django users<django-users@googlegroups.com>
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 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 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 attributes.

For example, a fluid sample type might have the fields:  volume,
concentration, pH, and expiration date.
A soil sample might have the fields:  Clay content, color, grain size,
moisture content.

All sample types will have the common fields sample ID, sample type,
date collected, collector, source, and storage location.

So I'll need a generic "Sample" table and then related tables for each
sample type.

The difficulty is that many sample types are still undefined, and will
have to be defined by the individual users.  That means they'll have
to have an interface that allows them to create tables and fields in
the database.  I suppose I can put together a form for that which will
ensure it gets done in a limited, consistent and standard way.

I'm thinking out loud here, but it's getting the feedback that helped
to clarify it.  Any other comments or suggestions will be welcome.

On Jun 18, 9:46 pm, Venkatraman S <venka...@gmail.com> wrote:
> On Sat, Jun 19, 2010 at 10:12 AM, Venkatraman S <venka...@gmail.com> 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, i do not think that this table would contain a billion records
> and even if it does, this design helps in sharding. Maintaining this system
> in latter case would be more of a db-admin or sys-admin job - and already
> there are many solutions in addition to sharding, when the size of a single
> table is HUGE. (when Facebook can contain the entire 32Gb profile data in
> the RAM, doesnt the world look small? ;)  )
>
> -V-http://twitter.com/venkasub

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Database Design Question

[Torsten Bronger]

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 attributes.
>
> For example, a fluid sample type might have the fields: volume,
> concentration, pH, and expiration date.  A soil sample might have
> the fields: Clay content, color, grain size, moisture content.
>
> All sample types will have the common fields sample ID, sample
> type, date collected, collector, source, and storage location.
>
> So I'll need a generic "Sample" table and then related tables for
> each sample type.

In our nanotech institute, we have already created a samples
database with Django.

We used an approach very similar to yours: There is the "Sample"
model with almost no fields -- more or less, just the sample name.

Then, there is a "Process" model with a timestamp, and an M2M
relationship with "Sample".

And finally, there is a plethora of models derived from "Process"
through multi-table inheritace.  Etching processes, deposition
processes, measurements etc.  Even properties inherent to a sample
like sample size or sample substate are organised in special
processes.

Now, the sample's datasheet simply is the list of all related
processes, in timestamp order.

> The difficulty is that many sample types are still undefined, and
> will have to be defined by the individual users.  That means
> they'll have to have an interface that allows them to create
> tables and fields in the database.  I suppose I can put together a
> form for that which will ensure it gets done in a limited,
> consistent and standard way.

We haven't thought about this yet, and we won't do this probably.
What we *may* implement someday is that the administrator can create
new processes without programming.  But this still includes
restarting the server.

On the other hand, we've defined a "general purpose" process with a
spreadsheet-like 2D array, and the user can set the column names
arbitrarily.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
   Jabber ID: torsten.bron...@jabber.rwth-aachen.de
  or http://bronger-jmp.appspot.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Database Design Question

[llanitedave]

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 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 attributes.

For example, a fluid sample type might have the fields:  volume,
concentration, pH, and expiration date.
A soil sample might have the fields:  Clay content, color, grain size,
moisture content.

All sample types will have the common fields sample ID, sample type,
date collected, collector, source, and storage location.

So I'll need a generic "Sample" table and then related tables for each
sample type.

The difficulty is that many sample types are still undefined, and will
have to be defined by the individual users.  That means they'll have
to have an interface that allows them to create tables and fields in
the database.  I suppose I can put together a form for that which will
ensure it gets done in a limited, consistent and standard way.

I'm thinking out loud here, but it's getting the feedback that helped
to clarify it.  Any other comments or suggestions will be welcome.

On Jun 18, 9:46 pm, Venkatraman S  wrote:
> 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, i do not think that this table would contain a billion records
> and even if it does, this design helps in sharding. Maintaining this system
> in latter case would be more of a db-admin or sys-admin job - and already
> there are many solutions in addition to sharding, when the size of a single
> table is HUGE. (when Facebook can contain the entire 32Gb profile data in
> the RAM, doesnt the world look small? ;)  )
>
> -V-http://twitter.com/venkasub

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Database Design Question

[Venkatraman S]

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, i do not think that this table would contain a billion records
and even if it does, this design helps in sharding. Maintaining this system
in latter case would be more of a db-admin or sys-admin job - and already
there are many solutions in addition to sharding, when the size of a single
table is HUGE. (when Facebook can contain the entire 32Gb profile data in
the RAM, doesnt the world look small? ;)  )

-V-
http://twitter.com/venkasub

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Database Design Question

[Venkatraman S]

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 etc

Define another tbl(tblname:sample_types): sampleid(this refers to
samples.sampleid) ,sampletype ,samplevalue
sampletype and samplevalue above would contain the relationship.

In your case (for eg) :
sampleid  sampeletype   samplevalue
1001Concentration   0.9

Prefer some other naming convention for sampletype-samplevalue.
(param:value?)

-V-
http://twitter.com/venkasub

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Database Design Question

[llanitedave]

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.

Each sample type has a particular set of attributes, some of which are
unique, others are shared with other sample types.

For example, a fluid sample might have "Concentration" as one
attribute, while a soil sample might have "Clay Content" as one.

My idea is to have a Samples table that contains the fields common to
all types of samples, and then a related table containing the
Attribute fields for each sample type.

The question is, should I use a separate table for each sample type,
or a single table for all of them, that displays only appropriate
fields in the view for a particular type?  There seem to be advantages
and disadvantages for each approach.  I can think of about a dozen
different types of samples that might need to be tracked offhand, but
there would probably be more. A single large table that has fields
"available" for the user to define their own sample types might be
better in some respects.

So, I'm looking at the choice between many smaller related tables,
that might get unwieldy in numbers of tables, or one large table that
might get unwieldy in terms of loading and keeping individual fields
organized.

I'm open for guidance!

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: design question - forms as meta-data to a model

[Walter Wefft]

On Jun 6, 5:23 am, Jason Beaudoin  wrote:
>
>  - I've got a model that defines "submissions", which are incoming
> messages from HTML forms on various websites and are fielded by admins
>  - each submission has a bunch of basic information related to the
> submission (where, when, etc), as well as the data submitted by the
> user (form input field)
>  - each form on each website is different, and will be different in the future
>  - allowing non-developers the ability to manage these forms would be
> really nice, so creating them through a frontend interface (as opposed
> to developers hardcoding forms) is a desirable goal
>  - the idea is that users would submit information from various source
> websites to a central repository via a number of forms all with
> different fields and varying in # of fields, field names, etc. the
> central repository is a place where everything is reviewed, where
> submissions are displayed in a "this is when it came in, from here,
> and this is what the user gave us" type of way.
>
> I'm not sure how to save the form information with each submission,
> given that each form will be different.. I'm used to defining specific
> forms and only accepting specific information.
>

Regarding form creation, you can create forms as it were procedurally:

from django.core.exceptions import ValidationError
from django.forms import forms
from django.forms import fields
from django.forms import widgets

# factory
def FormClass(name_, **kw):
return forms.DeclarativeFieldsMetaclass(name_, (forms.BaseForm,),
kw)

# widgets
Textarea = widgets.Textarea({'rows': '30'})

# fields
NameField = fields.CharField(label='Name', max_length=50)
BioField = fields.CharField(label='Bio', widget=Textarea,
required=False)

# validators
def clean_name(form):
if form.cleaned_data['name'].startswith('J'):
raise ValidationError("Invalid User")
return form.cleaned_data['name']

# forms
RegistrationForm = FormClass(
'frm1234',
name = NameField,
bio = BioField,
clean_name=clean_name,
)

print type(RegistrationForm)

form = RegistrationForm({'name': 'Bob'})
assert form.is_valid()

form = RegistrationForm({'name': 'Joe'})
assert not form.is_valid()

print form['name']
print form['name'].errors

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: design question - forms as meta-data to a model

[Sam Lai]

In the SQL world, you would probably store each form field value for
each submission as a row (or the entire form submission in a single
field, serialized to some known form; some DBs natively have an XML
field which might be useful).

In the noSQL world, however, this kind of situation is easier (for
most), because many don't have schemas which is your main problem.
However, because Django was designed for relational databases, even
django-norel seems to expect you to define your fields, effectively
locking you into a schema.

There might be some other choices here, but one way or another,
there'll be a fair bit of custom code going on.

On 6 June 2010 14:23, Jason Beaudoin  wrote:
> On Fri, Jun 4, 2010 at 2:42 AM, Russell Keith-Magee
>  wrote:
>> On Fri, Jun 4, 2010 at 12:03 PM, Jason Beaudoin  
>> wrote:
>>> Silence usually implies some key piece of documentation was missed, or
>>> was this just lost amongst more interesting posts? :)
>>
>> You've missed two important alternatives:
>>  * The people who can answer your question are busy
>>  * Nobody can understand your question.
>>
>> Personally, I fall into both these categories. I'm still trying to dig
>> myself out from tasks stemming from DjangoCon; and I really can't work
>> out what it is you're trying to do.
>
> You are fantastic :)
> My apologies, let me try to clarify:
>
>  - I've got a model that defines "submissions", which are incoming
> messages from HTML forms on various websites and are fielded by admins
>  - each submission has a bunch of basic information related to the
> submission (where, when, etc), as well as the data submitted by the
> user (form input field)
>  - each form on each website is different, and will be different in the future
>  - allowing non-developers the ability to manage these forms would be
> really nice, so creating them through a frontend interface (as opposed
> to developers hardcoding forms) is a desirable goal
>  - the idea is that users would submit information from various source
> websites to a central repository via a number of forms all with
> different fields and varying in # of fields, field names, etc. the
> central repository is a place where everything is reviewed, where
> submissions are displayed in a "this is when it came in, from here,
> and this is what the user gave us" type of way.
>
>
> I'm not sure how to save the form information with each submission,
> given that each form will be different.. I'm used to defining specific
> forms and only accepting specific information.
>
>
>> So - perhaps if you explain your problem in more detail, you might
>> have more luck getting a response.
>
> Indeed, this is sometimes a bit difficult to communicate with clarity.
>
>
> Regards,
>
> ~Jason
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: design question - forms as meta-data to a model

[Russell Keith-Magee]

On Sunday, June 6, 2010, Jason Beaudoin  wrote:
> On Fri, Jun 4, 2010 at 2:42 AM, Russell Keith-Magee
>  wrote:
>> On Fri, Jun 4, 2010 at 12:03 PM, Jason Beaudoin  
>> wrote:
>>> Silence usually implies some key piece of documentation was missed, or
>>> was this just lost amongst more interesting posts? :)
>>
>> You've missed two important alternatives:
>>  * The people who can answer your question are busy
>>  * Nobody can understand your question.
>>
>> Personally, I fall into both these categories. I'm still trying to dig
>> myself out from tasks stemming from DjangoCon; and I really can't work
>> out what it is you're trying to do.
>
> You are fantastic :)
> My apologies, let me try to clarify:
>
>  - I've got a model that defines "submissions", which are incoming
> messages from HTML forms on various websites and are fielded by admins
>  - each submission has a bunch of basic information related to the
> submission (where, when, etc), as well as the data submitted by the
> user (form input field)
>  - each form on each website is different, and will be different in the future
>  - allowing non-developers the ability to manage these forms would be
> really nice, so creating them through a frontend interface (as opposed
> to developers hardcoding forms) is a desirable goal
>  - the idea is that users would submit information from various source
> websites to a central repository via a number of forms all with
> different fields and varying in # of fields, field names, etc. the
> central repository is a place where everything is reviewed, where
> submissions are displayed in a "this is when it came in, from here,
> and this is what the user gave us" type of way.
>
>
> I'm not sure how to save the form information with each submission,
> given that each form will be different.. I'm used to defining specific
> forms and only accepting specific information.

In the normal mode, Django forms are designed to be statically defined
by the developer, and then displayed to the user. However, they can
actually be dynamically generated during runtime. The most common use
case for this that I have seen is to modify the default fields to make
the list of choices presented by a ChoiceField change dynamically
based upon some request-based property (like the current user).
However, you can use the same capability to add completely new fields
to the form - you just need to add to form.fields in the constructor
of the form.

That leaves the problem of deciding how to determine which extra
fields Need to be added to the form. This will require some
meta-programming on your part - essentially, defining a data model for
defining data models. I can't say think of any obvious good examples
of this that I can point you at; so a little experimentation will be
required on your part.

However, if you do it well, you may find that it is a good candidate
for a reusable application: something you can build as a standalone
capability that you can share with the community for others to use if
they find themselves in a similar situation.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: design question - forms as meta-data to a model

[Jason Beaudoin]

On Fri, Jun 4, 2010 at 2:42 AM, Russell Keith-Magee
 wrote:
> On Fri, Jun 4, 2010 at 12:03 PM, Jason Beaudoin  
> wrote:
>> Silence usually implies some key piece of documentation was missed, or
>> was this just lost amongst more interesting posts? :)
>
> You've missed two important alternatives:
>  * The people who can answer your question are busy
>  * Nobody can understand your question.
>
> Personally, I fall into both these categories. I'm still trying to dig
> myself out from tasks stemming from DjangoCon; and I really can't work
> out what it is you're trying to do.

You are fantastic :)
My apologies, let me try to clarify:

 - I've got a model that defines "submissions", which are incoming
messages from HTML forms on various websites and are fielded by admins
 - each submission has a bunch of basic information related to the
submission (where, when, etc), as well as the data submitted by the
user (form input field)
 - each form on each website is different, and will be different in the future
 - allowing non-developers the ability to manage these forms would be
really nice, so creating them through a frontend interface (as opposed
to developers hardcoding forms) is a desirable goal
 - the idea is that users would submit information from various source
websites to a central repository via a number of forms all with
different fields and varying in # of fields, field names, etc. the
central repository is a place where everything is reviewed, where
submissions are displayed in a "this is when it came in, from here,
and this is what the user gave us" type of way.


I'm not sure how to save the form information with each submission,
given that each form will be different.. I'm used to defining specific
forms and only accepting specific information.


> So - perhaps if you explain your problem in more detail, you might
> have more luck getting a response.

Indeed, this is sometimes a bit difficult to communicate with clarity.


Regards,

~Jason

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: design question - forms as meta-data to a model

[Russell Keith-Magee]

On Fri, Jun 4, 2010 at 12:03 PM, Jason Beaudoin  wrote:
> Silence usually implies some key piece of documentation was missed, or
> was this just lost amongst more interesting posts? :)

You've missed two important alternatives:
 * The people who can answer your question are busy
 * Nobody can understand your question.

Personally, I fall into both these categories. I'm still trying to dig
myself out from tasks stemming from DjangoCon; and I really can't work
out what it is you're trying to do.

In particular, you seem to be using the word "form" in a way that
isn't entirely consistent with normal Django form usage, but I can't
work out exactly what your usage entails. It sounds like you're trying
to use a model to dynamically define forms, but I'm not completely
certain about that.

So - perhaps if you explain your problem in more detail, you might
have more luck getting a response.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: design question - forms as meta-data to a model

[Jason Beaudoin]

Silence usually implies some key piece of documentation was missed, or
was this just lost amongst more interesting posts? :)


On Tue, Jun 1, 2010 at 9:54 PM, Jason Beaudoin  wrote:
> Hi,
>
> I've a situation where the following functionality is desirable..
>
>  - one central model is used and interacted with by users
>  - forms (multiple on multiple sites, pick a number for each.. 5 or
> 50, doesn't matter) are submitted by anonymous users and associated
> with this central model.. so these forms are sort of meta-data..
>  - it would be nice to be able to define a new form via the admin
> panel and allow this to be picked up more or less dynamically by the
> rest of the application - so once defined, a site could then start
> submitting forms and have them associated with and displayed as part
> of other instances of this model, no other code or (manual) db updates
> would really be necessary
>
> I'm an intermediate django user, and are pretty well-rooted in various
> aspects of django development, though I haven't really wrapped my head
> around the best way to implement these forms, the model, and the
> connection between the two.
>
> Thoughts?
>
>
> thanks!
>
> ~Jason
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

design question - forms as meta-data to a model

[Jason Beaudoin]

Hi,

I've a situation where the following functionality is desirable..

 - one central model is used and interacted with by users
 - forms (multiple on multiple sites, pick a number for each.. 5 or
50, doesn't matter) are submitted by anonymous users and associated
with this central model.. so these forms are sort of meta-data..
 - it would be nice to be able to define a new form via the admin
panel and allow this to be picked up more or less dynamically by the
rest of the application - so once defined, a site could then start
submitting forms and have them associated with and displayed as part
of other instances of this model, no other code or (manual) db updates
would really be necessary

I'm an intermediate django user, and are pretty well-rooted in various
aspects of django development, though I haven't really wrapped my head
around the best way to implement these forms, the model, and the
connection between the two.

Thoughts?


thanks!

~Jason

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Templates design question

[andreas schmid]

you could create a template module where you put in the logic to dipslay
the content of the post:

 Hello,
>
> I'm writing some simple webblog, just for self teaching, and I have a
> question how to do better. Here is the situation, I have base.html, I
> have blog.html which extends base. Now in that blog I would like to
> put posts, full text posts, without comments, and link to the post
> only with comments. And I run out of ideas how to make it without
> repeating html. For e.g. in blog.html I have:
>
> {% extends "base.html" %}
> {% for entry in entries %}
>
> 
> http://groups.google.com/group/django-users?hl=en.

Templates design question

[R. K.]

Hello,

I'm writing some simple webblog, just for self teaching, and I have a
question how to do better. Here is the situation, I have base.html, I
have blog.html which extends base. Now in that blog I would like to
put posts, full text posts, without comments, and link to the post
only with comments. And I run out of ideas how to make it without
repeating html. For e.g. in blog.html I have:

{% extends "base.html" %}
{% for entry in entries %}

http://groups.google.com/group/django-users?hl=en.

Model design question: Inheritance? GenericRelation? ...?

[Achim Domma]

Hi,

I have different models A,B,C which all will have exactly on Address.
If I query instances of A,B,C I usually will also need the related
address. I also want to query all instances of A,B,C which have a
certain zip code for example. What's the best and most efficient way
to model that in django?

Using a common base class sound like the most efficient solution, but
feels wrong from a OO point of view. Using a GenericRelation sound
like the cleaner solution to me, but I fear that the resulting
statements might be slow.

Any hint or other solution?

cheers,
Achim

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Design Question - Extending a model

[Jason Beaudoin]

On Mon, Jan 11, 2010 at 12:00 PM, Igor  wrote:
> Thanks a lot - I didn't know about generic relations, and will
> definitely look at them - right now :).

I start thinking about extending models (and other DRY mode/db
methods) when I see myself repetitively typing out too many fields.

~J
-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Design Question - Extending a model

[Igor]

Thanks a lot - I didn't know about generic relations, and will
definitely look at them - right now :).

The minimal subset - and that's where I'm trying to follow DRY - boils
down to a Title,  a slug, Content HTML of the entry, maybe a couple
more things - all are very much like what you would expect to have in
a blog entry. It of course will also have comments, tags, category
etc. - these should all be standard.

But then, I want to be able add little things like event dates to it.
And I'm trying to avoid having to create a whole new template just
because I want to have one (or a few) extra -s on the page which
will display the event's dates. But this is the thing - event dates
are not the only one thing I want to display. In another case I want
it to be the same thing but have a rating... Maybe you're right and
all of those things should come as generic addons, since ratings,
comments etc are applicable to anything.

I'm really scared of your last point - redesigning relationships. This
seems to be the ugliest part if one happens to have to do this.

I have over 12 years of Web experience... and still looking for the
holy grail of OOD :) Hence are all the concerns.

I'd be happy to see references to any more examples, guides etc... I'm
sure there are some, but they're somehow difficult to find..

Additionally, I want to have one way of displaying it within HTML so I
don't need

On Jan 11, 5:21 pm, Ethan Jucovy  wrote:
> My instinct is that you may be trying to be too generic.  Without knowing
> more details, a "generic Entry" sounds a lot like .. a database record. :)
> Django's model.Model base class already does a great job at being easily
> extensible.
>
> Is there a specific minimal-but-interesting set of database fields that you
> want shared among all your models?  If so, you might want to use an abstract
> base class that all your real models inherit from.[1]
>
> Is there a specific set of functionalities that you want several types of
> persistent objects to support?  For this, unless you have very specific
> pluggability requirements, I would probably just define the functionality in
> a standalone function and informally adapt or handle each type as needed.
>
> Generic foreign keys[2] might also be helpful, if your requirements sound
> anything like "I have a Tag model, and I want to be able to attach Tags to
> any kind of object" or "I have a Comment model, and I want to be able to
> attach Comments to any kind of object."
>
> There are plenty of other approaches you could use too, of course, depending
> on your particular requirements.  When in doubt keep it simple and keep it
> in Python -- it's a pain to refactor complex model relationships if you
> change your mind later on; far less so to replace ad-hoc Python functions
> with complex model relationships when you realize you actually need them. :)
>
> -Ethan
>
> [1]http://docs.djangoproject.com/en/dev/topics/db/models/#abstract-base-...
> [2]http://www.djangoproject.com/documentation/models/generic_relations/
>
> On Mon, Jan 11, 2010 at 9:24 AM, Igor  wrote:
> > Hi all,
>
> > This is a general question for whoever is good with best practices for
> > Django design (software design that is).
>
> > I'd like to implement (well, kinda have implemented), a generic Entry
> > object that would be good for several uses. For example, an Event
> > (such as, say, a website presentation) is just an Entry with one or
> > more start/end dates attached. A business listing in a catalogue is
> > basically an Entry with some other properties such as business rating
> > or whatever else. There's more to it but I think you get the idea - I
> > want the Entry to be EASILY extensible with more features. This
> > includes easily extending the templates if possible.
>
> > Am I trying to be too generic? Or, if not, what's a good approach to
> > take - I can use model inheritance, or an Event model could have an
> > Entry as a Foreign Key (which is what it does now). Or maybe there's a
> > whole other approach that I've missed but everyone else does? In any
> > case, how difficult would it be to access, say, all events that have a
> > post, or the other way around?
>
> > I'm sorry if I'm not precise or if this sounds stupid. I have a great
> > trust in Django, but so far I've been advancing a bit slowly. It would
> > be great to hear your opinions.
>
> > Thanks,
> > Igor
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To post to this group, send email to django-us...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-users+unsubscr...@googlegroups.com
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/django-users?hl=en.
-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, 

Re: Design Question - Extending a model

[Ethan Jucovy]

My instinct is that you may be trying to be too generic.  Without knowing
more details, a "generic Entry" sounds a lot like .. a database record. :)
Django's model.Model base class already does a great job at being easily
extensible.

Is there a specific minimal-but-interesting set of database fields that you
want shared among all your models?  If so, you might want to use an abstract
base class that all your real models inherit from.[1]

Is there a specific set of functionalities that you want several types of
persistent objects to support?  For this, unless you have very specific
pluggability requirements, I would probably just define the functionality in
a standalone function and informally adapt or handle each type as needed.

Generic foreign keys[2] might also be helpful, if your requirements sound
anything like "I have a Tag model, and I want to be able to attach Tags to
any kind of object" or "I have a Comment model, and I want to be able to
attach Comments to any kind of object."

There are plenty of other approaches you could use too, of course, depending
on your particular requirements.  When in doubt keep it simple and keep it
in Python -- it's a pain to refactor complex model relationships if you
change your mind later on; far less so to replace ad-hoc Python functions
with complex model relationships when you realize you actually need them. :)

-Ethan

[1]
http://docs.djangoproject.com/en/dev/topics/db/models/#abstract-base-classes
[2] http://www.djangoproject.com/documentation/models/generic_relations/

On Mon, Jan 11, 2010 at 9:24 AM, Igor  wrote:

> Hi all,
>
> This is a general question for whoever is good with best practices for
> Django design (software design that is).
>
> I'd like to implement (well, kinda have implemented), a generic Entry
> object that would be good for several uses. For example, an Event
> (such as, say, a website presentation) is just an Entry with one or
> more start/end dates attached. A business listing in a catalogue is
> basically an Entry with some other properties such as business rating
> or whatever else. There's more to it but I think you get the idea - I
> want the Entry to be EASILY extensible with more features. This
> includes easily extending the templates if possible.
>
> Am I trying to be too generic? Or, if not, what's a good approach to
> take - I can use model inheritance, or an Event model could have an
> Entry as a Foreign Key (which is what it does now). Or maybe there's a
> whole other approach that I've missed but everyone else does? In any
> case, how difficult would it be to access, say, all events that have a
> post, or the other way around?
>
> I'm sorry if I'm not precise or if this sounds stupid. I have a great
> trust in Django, but so far I've been advancing a bit slowly. It would
> be great to hear your opinions.
>
> Thanks,
> Igor
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>
>
>
-- 

You received this message because you are subscribed to the Google Groups "Django users" group.

To post to this group, send email to django-us...@googlegroups.com.

To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

Design Question - Extending a model

[Igor]

Hi all,

This is a general question for whoever is good with best practices for
Django design (software design that is).

I'd like to implement (well, kinda have implemented), a generic Entry
object that would be good for several uses. For example, an Event
(such as, say, a website presentation) is just an Entry with one or
more start/end dates attached. A business listing in a catalogue is
basically an Entry with some other properties such as business rating
or whatever else. There's more to it but I think you get the idea - I
want the Entry to be EASILY extensible with more features. This
includes easily extending the templates if possible.

Am I trying to be too generic? Or, if not, what's a good approach to
take - I can use model inheritance, or an Event model could have an
Entry as a Foreign Key (which is what it does now). Or maybe there's a
whole other approach that I've missed but everyone else does? In any
case, how difficult would it be to access, say, all events that have a
post, or the other way around?

I'm sorry if I'm not precise or if this sounds stupid. I have a great
trust in Django, but so far I've been advancing a bit slowly. It would
be great to hear your opinions.

Thanks,
Igor



-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: design question: storing history

[Shawn Milochik]

It sounds like, for auditing purposes, there should be a model for storing each 
"hours worked" entry.

Also, the hours estimated should not be reduced in the database -- there should 
be a method of your model which returns the remaining hours by subtracting the 
sum of the worked hours from the estimated hours. This will make it easier when 
you want to look up the estimated hours.

Alternately, you can keep all your hours worked info in a list or dictionary, 
serialized with simplejson, and stored in a text field in your model. That 
would avoid the extra table, and you could use the property() keyword to create 
all the nice methods. I don't know which is better for your situation, given 
performance and how your application will be used.

Shawn

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

design question: storing history

[tom]

Hi,

I have a Model which tracks tasks for a project. This model should
have
 - hours estimated
 - hours worked
on it.

Everytime someone updates one of those fields, the hours worked should
be increased and should also be stored to be used for time reporting.
e.g. hours worked: 12.21.09 2 hours, 12.22.09 3 hours and so forth
The hours worked shall be reduced.

Would it make sense to have a foreign key to different models for
hours worked and hours estimated, or shall I use the history and sum
up the hours? Any ideas would be very much appreciated.

-tom

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: A Design Question

[John M]

Even though it is outside the scope, I'd say start simple and build
slowly with related tables, those are easy to add to a system.  I'd
probably find the attributes you'd like to capture in the 'extra
details' and start putting them in a table.  Determine what the
purpose of these attributes are, searching, reporting, calculations,
etc and that should help you determine if you need more than one
'extra' table.

HTH

John

On Nov 29, 10:36 am, Ramdas S  wrote:
> This is probably outside Django. But I am checking out since I am building
> it with Django.
>
> I am building a specialized closed group social networking web site for
> special set of medical practitioners. Idea for my client is to be a mini-
> LinkedIn of sorts for this small community.
>
> We want to capture as many details as possible from some clinical practices,
> to education, work experience, papers submitted etc. However at registration
> time we want to limit it to just the basic details like name, email and may
> be some license number.
>
> However over a period of time we would like the user to add details.
>
> Do I build one large UserProfile Table, with ForeignKey to colleges,
> specializations etc or do I break it up into number of smaller profiles, and
> link each profile to a User. What's the best practice?
>
> --
> Ramdas S

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: A Design Question

[Steve S.]

This /is/ outside the scope of Django.

"Database normalization" and "Database design" are the google query
you're looking for to learn more about this, though. Here are some
links that may steer you in the right direction:

http://en.wikipedia.org/wiki/Database_normalization
http://databases.about.com/od/specificproducts/a/normalization.htm
http://devhood.com/tutorials/tutorial_details.aspx?tutorial_id=95
http://en.wikipedia.org/wiki/Database_design
http://databases.about.com/od/specificproducts/Database_Design.htm

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

A Design Question

[Ramdas S]

This is probably outside Django. But I am checking out since I am building
it with Django.

I am building a specialized closed group social networking web site for
special set of medical practitioners. Idea for my client is to be a mini-
LinkedIn of sorts for this small community.

We want to capture as many details as possible from some clinical practices,
to education, work experience, papers submitted etc. However at registration
time we want to limit it to just the basic details like name, email and may
be some license number.

However over a period of time we would like the user to add details.

Do I build one large UserProfile Table, with ForeignKey to colleges,
specializations etc or do I break it up into number of smaller profiles, and
link each profile to a User. What's the best practice?



-- 
Ramdas S

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Design question

[Brian McKeever]

It's a trade-off. Loose coupling allows you to modify the structure of
your program easier, but doing so in this case is going to lead to a
performance hit.

That said, this isn't crazy coupling we're suggesting. It's not like
we need to know anything about the user model to do this or that
anything in the user model depends on this.

I mean, you need to think about the specific application, but if
you're writing a blog application, are you really going to want to
restructure your program so that entries aren't owned by users? Are
entries owned by groups a realistic possibility? Should companies be
treated differently from users? I'd say no to both, but my blog
application may differ from yours.

On Sep 24, 9:37 am, ringemup  wrote:
> So the tighter coupling implied by each entry knowing about the user
> profile shouldn't be a subject of concern?
>
> On Sep 23, 11:05 pm, Brian McKeever  wrote:
>
> > I remember a quote from either headfirst java or design patterns that
> > said something like:
> > "The key to inheritance is to abstract functionality."
>
> > I realize we're not talking about inheritance, but I think it still
> > applies.
>
> > It may make logical sense that a user object has a blog that has
> > entries, but unless a blog object adds functionality, you should just
> > say that a user has entries.
>
> > On Sep 21, 8:33 pm, ringemup  wrote:
>
> > > There's a pattern I keep running into, and I've been wondering if
> > > anyone who's encountered it before has an opinion on how best to deal
> > > with it:
>
> > > Imagine you have an app that could theoretically stand on its own --
> > > for now let's say a schedule, but it could be anything (an image
> > > gallery, a blog, etc).  This app has multiple items per "app
> > > instance" (i.e. every schedule has multiple events; every blog has
> > > multiple entries, etc).
>
> > > For your main project, tou want every user to have one instance of
> > > what the app provides.
>
> > > It seems more pluggable to have an intermediary parent model (Schedule
> > > or Blog or Gallery) between the app items (events, entries, etc) and
> > > the user / user profile than to assign the items directly to the
> > > user.  I.e. each Event has a "schedule" FK and the user profile has a
> > > "schedule" one-to-one field, rather than giving each event a "user"
> > > FK.
>
> > > On the other hand, the intermediary model is rather pointless if it
> > > doesn't have any fields of its own.  It also results in more demanding
> > > queries and interferes with the use of select_related.
>
> > > How do you typically handle this case?
>
> > > Thanks!
--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Design question

[ringemup]

So the tighter coupling implied by each entry knowing about the user
profile shouldn't be a subject of concern?

On Sep 23, 11:05 pm, Brian McKeever  wrote:
> I remember a quote from either headfirst java or design patterns that
> said something like:
> "The key to inheritance is to abstract functionality."
>
> I realize we're not talking about inheritance, but I think it still
> applies.
>
> It may make logical sense that a user object has a blog that has
> entries, but unless a blog object adds functionality, you should just
> say that a user has entries.
>
> On Sep 21, 8:33 pm, ringemup  wrote:
>
> > There's a pattern I keep running into, and I've been wondering if
> > anyone who's encountered it before has an opinion on how best to deal
> > with it:
>
> > Imagine you have an app that could theoretically stand on its own --
> > for now let's say a schedule, but it could be anything (an image
> > gallery, a blog, etc).  This app has multiple items per "app
> > instance" (i.e. every schedule has multiple events; every blog has
> > multiple entries, etc).
>
> > For your main project, tou want every user to have one instance of
> > what the app provides.
>
> > It seems more pluggable to have an intermediary parent model (Schedule
> > or Blog or Gallery) between the app items (events, entries, etc) and
> > the user / user profile than to assign the items directly to the
> > user.  I.e. each Event has a "schedule" FK and the user profile has a
> > "schedule" one-to-one field, rather than giving each event a "user"
> > FK.
>
> > On the other hand, the intermediary model is rather pointless if it
> > doesn't have any fields of its own.  It also results in more demanding
> > queries and interferes with the use of select_related.
>
> > How do you typically handle this case?
>
> > Thanks!
--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Design question

[Brian McKeever]

I remember a quote from either headfirst java or design patterns that
said something like:
"The key to inheritance is to abstract functionality."

I realize we're not talking about inheritance, but I think it still
applies.

It may make logical sense that a user object has a blog that has
entries, but unless a blog object adds functionality, you should just
say that a user has entries.

On Sep 21, 8:33 pm, ringemup  wrote:
> There's a pattern I keep running into, and I've been wondering if
> anyone who's encountered it before has an opinion on how best to deal
> with it:
>
> Imagine you have an app that could theoretically stand on its own --
> for now let's say a schedule, but it could be anything (an image
> gallery, a blog, etc).  This app has multiple items per "app
> instance" (i.e. every schedule has multiple events; every blog has
> multiple entries, etc).
>
> For your main project, tou want every user to have one instance of
> what the app provides.
>
> It seems more pluggable to have an intermediary parent model (Schedule
> or Blog or Gallery) between the app items (events, entries, etc) and
> the user / user profile than to assign the items directly to the
> user.  I.e. each Event has a "schedule" FK and the user profile has a
> "schedule" one-to-one field, rather than giving each event a "user"
> FK.
>
> On the other hand, the intermediary model is rather pointless if it
> doesn't have any fields of its own.  It also results in more demanding
> queries and interferes with the use of select_related.
>
> How do you typically handle this case?
>
> Thanks!
--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Design question

[ringemup]

There's a pattern I keep running into, and I've been wondering if
anyone who's encountered it before has an opinion on how best to deal
with it:

Imagine you have an app that could theoretically stand on its own --
for now let's say a schedule, but it could be anything (an image
gallery, a blog, etc).  This app has multiple items per "app
instance" (i.e. every schedule has multiple events; every blog has
multiple entries, etc).

For your main project, tou want every user to have one instance of
what the app provides.

It seems more pluggable to have an intermediary parent model (Schedule
or Blog or Gallery) between the app items (events, entries, etc) and
the user / user profile than to assign the items directly to the
user.  I.e. each Event has a "schedule" FK and the user profile has a
"schedule" one-to-one field, rather than giving each event a "user"
FK.

On the other hand, the intermediary model is rather pointless if it
doesn't have any fields of its own.  It also results in more demanding
queries and interferes with the use of select_related.

How do you typically handle this case?

Thanks!
--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Design question: User vs. UserProfile

[Léon Dignòn]

The user model, because the model defined by AUTH_PROFILE_MODULE is
intended to be an extension to the actual user model. Namely the
profile.

Why would you bind something to a user's profile, instead of the user
itsself? If you want to "allow records of people without Users", then
use blank=True and null=True at the foreign key (here: model Song).

-ld

On Sep 18, 6:21 pm, Tiago Serafim  wrote:
> I`d go with the first. It`s easier to get the current logged in user and all
> other pluggable apps use User, so it's a common thing to do and you can
> integrate things easily .
--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Design question: User vs. UserProfile

[Tiago Serafim]

I`d go with the first. It`s easier to get the current logged in user and all
other pluggable apps use User, so it's a common thing to do and you can
integrate things easily .

--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Design question: User vs. UserProfile

[Grant Livingston]

I'm still making my first site with django so I don't how much weight my
opinion has, but I used a seperate profile for ForeignKeys. I don't know
why, it just seemed logical at the time. It is easer as you can refer to
whats in a users profile easier. You can put things like {{
song.profile.user.username }} or {{ song.profile.song_set }} .

--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Database design question

[ringemup]

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(max_length=32, unique=True)
parent_account = models.ForeignKey('self', related_name='children',
null=True, blank=True)

def __unicode__(self):
return '%s owned by %s' % (self.alias, self.get_owner())

def save(self, force_insert=False, force_update=False):
if not Account.is_valid_parent_or_child(self.user,
self.parent_account):
raise AccountInheritanceError
super(Account, self).save(force_insert, force_update)

def get_canonical_alias(self):
if self.is_child():
return self.parent_account.get_canonical_alias()
return self.alias

def get_owner(self):
if self.is_child():
return self.parent_account.get_owner()
return self.user

@staticmethod
def is_valid_parent_or_child(user, parent_account):
# We need either a user (meaning this is a primary account)
# or a parent (meaning this is a child account), but not both
if bool(user) == bool(parent_account):
return False
if parent_account.is_child():
return False
return True

def is_parent(self):
return bool(self.user)

def is_child(self):
return bool(self.parent_account)

I'll probably end up shunting any required account fields into a
Profile model and either a)attaching that to Account with a nullable
one-to-one relationship, and making that required for parent accounts;
or b) making the Profile model the AUTH_PROFILE_MODULE rather than
Account (which is currently).
--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Database design question

[ringemup]

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 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?
>
> > 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 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 and such.
>
> > > > Since one will always have to be declared before the other, is there
> > > > any way to do this?
>
> > > What I would recommend is to drop the ForeignKey in the Account table.
> > You
> > > can always retrieve the set of Aliases for an Account based on the
> > > ForeignKey from Alias to Account. I believe that you will even be able to
> > > access Account.alias_set in your code, though if not you can always get
> > > Alias.objects.filter(Account_id=xx) and for the primary you will be able
> > to
> > > say either Account.alias_set.filter(parent__isnull=True)or
> > > Alias.objects.filter(Account_id=xx).filter(parent__isnull=True)
--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Database design question

[Joshua Russo]

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?
>
>
> 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 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 and such.
> >
> > > Since one will always have to be declared before the other, is there
> > > any way to do this?
> >
> > What I would recommend is to drop the ForeignKey in the Account table.
> You
> > can always retrieve the set of Aliases for an Account based on the
> > ForeignKey from Alias to Account. I believe that you will even be able to
> > access Account.alias_set in your code, though if not you can always get
> > Alias.objects.filter(Account_id=xx) and for the primary you will be able
> to
> > say either Account.alias_set.filter(parent__isnull=True)or
> > Alias.objects.filter(Account_id=xx).filter(parent__isnull=True)
> >
>

--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Database design question

[ringemup]

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 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 and such.
>
> > Since one will always have to be declared before the other, is there
> > any way to do this?
>
> What I would recommend is to drop the ForeignKey in the Account table. You
> can always retrieve the set of Aliases for an Account based on the
> ForeignKey from Alias to Account. I believe that you will even be able to
> access Account.alias_set in your code, though if not you can always get
> Alias.objects.filter(Account_id=xx) and for the primary you will be able to
> say either Account.alias_set.filter(parent__isnull=True)or
> Alias.objects.filter(Account_id=xx).filter(parent__isnull=True)
--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Database design question

[Joshua Russo]

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 validation purposes -- and not just in
> ForeignKey declarations and such.
>
> Since one will always have to be declared before the other, is there
> any way to do this?


What I would recommend is to drop the ForeignKey in the Account table. You
can always retrieve the set of Aliases for an Account based on the
ForeignKey from Alias to Account. I believe that you will even be able to
access Account.alias_set in your code, though if not you can always get
Alias.objects.filter(Account_id=xx) and for the primary you will be able to
say either Account.alias_set.filter(parent__isnull=True)or
Alias.objects.filter(Account_id=xx).filter(parent__isnull=True)

--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---