Re: DRY forms

[S Basl]

Apologies, I seem to have misunderstood the situation in my haste to be of
assistance.  I admit I'm no Django/Python whiz, more of a talented(?)
dabbler.  Maybe someone else can correct me, but it seems that save() will
always hit the entire row if you use a single model. Does save(f

It seems a bit hacky, but what about creating a method to parse the
modelform's inner Meta.fields then generate and execute a custom UPDATE
statement? This might be a bit more difficult if you're using exclude rather
than fields. To keep it DRY attach this method to a subclass of modelform
then make your existing modelforms subclasses of this.

This seems like a lot more work than aught be necessary, so you may be best
off waiting for someone more knowledgeable than me to chime in.



On Wed, Oct 20, 2010 at 3:34 AM, simonty  wrote:

> I can't change the database design. Even if I could, that would still
> mean I would have to define a model and a modelform for each table,
> no?
>
> On Oct 20, 6:13 pm, srb...@gmail.com wrote:
> > Can you just break the table up into several tables connected with
> one-to-one relations? Maybe look at the model forms you're using the most as
> a guide for which fields to include in the new tables?
> > Sent from my Verizon Wireless BlackBerry
> >
> > -Original Message-
> > From: simonty 
> >
> > Sender: django-users@googlegroups.com
> > Date: Tue, 19 Oct 2010 23:16:38
> > To: Django users
> > Reply-To: django-users@googlegroups.com
> > Subject: DRY forms
> >
> > Hello,
> > I have a database table with about 100 fields.
> > I have a number of forms with only a few  fields in each form based on
> > the fields in the table.
> > If I create one massive django model to represent the table and a
> > number of modelforms based on
> > the django model, this becomes inefficent because every time I update
> > one of my small modelforms (
> > which contain only a few fields), all fields in the table will get
> > updated. I can see this when I inspect the
> > sql query.
> > Alternatively I can create small django models and base my modelforms
> > on those but this isn't very DRY.
> > Its a alot of work.
> > Ideally, when I call save() on my modelform, I only want the fields on
> > my form to be updated. This makes sense because I am saving the
> > information in the form, not the entire model.
> > Could anyone make any suggestions for the above scenario?
> > Many 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-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.
>
>

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

[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,  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 
> Date: Fri, 18 Jun 2010 23:27:55
> To: Django users
> Subject: Re: Database Design Question
>
> Thanks for the response, Venkatraman.  You're right that I don't
> anticipate a huge number of records here -- a few 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.
>
>

-- 
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: Is there a way to create a new database table other than model?

[S Basl]

If you absolutely need to do so, you can execute raw sql queries to do
whatever you need using Django. The docs are here:
http://docs.djangoproject.com/en/1.2/topics/db/sql/

However, it's probably
a 'bad' idea to go mucking about with sql if you can at all avoid it.

On Tue, Nov 23, 2010 at 8:26 AM, ringemup  wrote:

> Perhaps there's another way to accomplish your goal.  Why do you want
> a table for each game?
>
> On Nov 23, 5:14 am, vbs  wrote:
> > Hi all,
> >
> > This is my situation, I want to make a web based game-hall.
> > I have a model named Game. When I add a new game from the admin panel,
> > a new record will be added to the database table assigned to model
> > Game. This is what django does.
> > And at the same time, I also want a new database table to be created,
> > named as the name of the new game, or with some prefix. It's best to
> > have a model assigned to this table.
> >
> > Is there any way to do this?
> >
> > Thank you.
>
> --
> 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: Is there a way to create a new database table other than model?

[S Basl]

None that I know of, but I am no Django guru. I get the feeling I'm missing
something about your situation however. It seems like you should be able to
accomplish what you want, saving unique info about each game, without
per-game tables. You have a many to many relationship between games and
users (ie each user can have multiple games & each game can have multiple
users), yes?  If so, you can store additional information in the bridge
table that Django creates. Check the docs for ManyToMany fields:
http://docs.djangoproject.com/en/1.2/ref/models/fields/#django.db.models.ManyToManyField
 &
http://docs.djangoproject.com/en/1.2/topics/db/models/#intermediary-manytomany



On Tue, Nov 23, 2010 at 8:55 AM, Li You  wrote:

> Because I want to save user's info about each game. And the best way
> is to save the info by each game.
>
> On Tue, Nov 23, 2010 at 9:26 PM, ringemup  wrote:
> > Perhaps there's another way to accomplish your goal.  Why do you want
> > a table for each game?
> >
> > On Nov 23, 5:14 am, vbs  wrote:
> >> Hi all,
> >>
> >> This is my situation, I want to make a web based game-hall.
> >> I have a model named Game. When I add a new game from the admin panel,
> >> a new record will be added to the database table assigned to model
> >> Game. This is what django does.
> >> And at the same time, I also want a new database table to be created,
> >> named as the name of the new game, or with some prefix. It's best to
> >> have a model assigned to this table.
> >>
> >> Is there any way to do this?
> >>
> >> Thank you.
> >
> > --
> > 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.
> >
> >
>
>
>
> --
> Best Regards!
>
> Li You
> University of Science and Technology of China
>
> --
> 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.