single-row database tables for properties

[barry.ro...@gmail.com]

I wanted a way to store 'properties' - single values over an app (or
project) that control the apps behaviour, for example a title to appear
on the page, or whether to display threads expanded or not in a forum.
I thought it would be nice to have these settings configurable from the
Admin interface, rather than editing a settings.py file.

So I discovered if you override 'save' and 'delete' in your model with:

def save(self):
self.id=1
super(mySettings, self).save()

def delete(self):
pass

then if you add a new row it just replaces the id=1 row, and if you
delete a row, nothing happens. If you create the row using the initial
SQL feature then you can be (almost) sure that there's only ever one
row in the table. Then when your view code needs to get a value, it
just queries the mySettings table and gets it.

Seems kinda neat, but obviously some people may be confused when 'add
mySetttings' doesnt actually add anything, and 'delete' doesnt actually
delete it. Would there be enough demand for this kinda thing to make it
a separate class of model, such that you could do:

class mySettings(models.Properties):

and then tweak the admin screens slightly to compensate for the
different behaviour?

Barry

[Ned Batchelder]

barry.ro...@gmail.com wrote:
> I wanted a way to store 'properties' - single values over an app (or
> project) that control the apps behaviour, for example a title to appear
> on the page, or whether to display threads expanded or not in a forum.
> I thought it would be nice to have these settings configurable from the
> Admin interface, rather than editing a settings.py file.
>
> So I discovered if you override 'save' and 'delete' in your model with:
>
> def save(self):
> self.id=1
> super(mySettings, self).save()
>
> def delete(self):
> pass
>
> then if you add a new row it just replaces the id=1 row, and if you
> delete a row, nothing happens. If you create the row using the initial
> SQL feature then you can be (almost) sure that there's only ever one
> row in the table. Then when your view code needs to get a value, it
> just queries the mySettings table and gets it.
>

I'm not quite sure I understand: it seems like you'd need a different
table for each property? That seems like a poor design. Why not simply
have a table with two columns: name and value, and use a row for each
setting? Then you don't have to overload save to create confusing
behavior in the first place, and you get a simpler database schema.

--
Ned Batchelder, http://nedbatchelder.com

[barry.ro...@gmail.com]

No you dont need a different table for each property, one table stores
all the properties that you want to collect together.

The problem with the (name,value) approach is that all the values have
to be the same type, so you cant present some properties as text, some
as boolean, and some as drop-down choices. Also you might want to
constrain the set of allowed names, and not allow additions.

[Ned Batchelder]

I see now. You are adding new columns for the different properties,
right? There's no example in your original posting.

You are right: the name, value method does restrict you to only one
value type.

[barry.ro...@gmail.com]

Here's my example then:

class Property(models.Model):
class Admin:
pass

showGone = models.BooleanField(default=False)
goneGroup = models.CharField(maxlength=100)

def save(self):
""" save, but set id to 1 """
self.id=1
super(Property, self).save()

def delete(self):
pass

def __str__(self):
return "Properties: "+" Show gone: "+str(self.showGone)+", Gone
Group: "+str(self.goneGroup)

My motivation here was to have a group of users that I can either show
or not show in a listing. The properties here control whether that flag
is set or not and the name of the group. Its almost a proof-of-concept
but there are plenty of other examples.