Re: Suggestion: DictionaryField

[Yuri Baburov]

Hi Łukasz, Mikhail,

You can go further and create DictionaryField.

But I see the problems you will get with it:
1) You won't be able to refer to the model afterwards, since it's not
defined in models.py as global.
2) I prefer to make DictionaryModel key the primary_key when
appropriate, you'll need that option.
3) Additional fields or methods can appear at any time later, making
such "economy" almost useless.

So, my only wish is better builtin autocomplete widget for admin and
regular usage.
Current default one (for raw_id_fields) looks overcomplicated.
Unfortunately, The Right autocomplete widget for django admin doesn't exist yet.

2010/1/18 Łukasz Rekucki :
> 2010/1/17 Simon Meers :
>> I had considered designing something like this last week. It does seem to be
>> a common requirement -- any situation where a simple field would be almost
>> suitable but for the fact you'd like to avoid duplicates and allow fast
>> selection of existing values. A Field shortcut could be commonly used to
>> avoid the creation of separate models. Another example:
>>
>>     class Suburb(models.Model):
>>     name = models.CharField(max_length=64, unique=True)
>>
>>     class Meta:
>>     ordering = ['name']
>>
>>     def __unicode__(self):
>>     return u'%s' % self.name
>>
>>
>>     class School(models.Model):
>>     name = models.CharField(max_length=64, unique=True)
>>
>>     class Meta:
>>     ordering = ['name']
>>
>>     def __unicode__(self):
>>     return u'%s' % self.name
>>
>>
>>     class Student(models.Model):
>>     school = models.ForeignKey(School)
>>     suburb = models.ForeignKey(Suburb)
>>     # ...
>>
>> could be replaced with simply:
>>
>>     class Student(models.Model):
>>     school = models.DictionaryField(max_length=64)
>>     suburb = models.DictionaryField(max_length=64)
>>     # ...
>>
>> I'm not 100% sold on the name, but I think it is on the right track. I'm
>> also wondering whether it could be worth catering for types other than
>> CharField as well. For example:
>>
>>     team_number = models.DictionaryField(type=models.IntegerField)
>>
>> This makes me wonder whether perhaps this could be generically applied to
>> all fields via a Field.__init__ kwarg instead:
>>
>>     class Student(models.Model):
>>         school = models.CharField(max_length=64, lookup=True)
>>         suburb = models.CharField(max_length=64, lookup=True)
>>         team_number = models.IntegerField(lookup=True)
>>
>> Either way, these fields could then be stored in separate tables
>> appname_modelname_fieldname, with a single field of the appropriate type
>> (named 'value' or similar). It would be nice to also provide external access
>> to these auto-generated models via something like Student.school.objects.
>> Currently Student.school would be a ReverseSingleRelatedObjectDescriptor,
>> and objects can be accessed via
>> Student.school.field.related.parent_model.objects.all(), but a shortcut
>> would be nice.
>>
>> The auto-generated models could provide ordering by value, a unique
>> constraint on the field, and a simple __unicode__ method like the examples
>> above.
>
> This seems like a lot of work and tweeks, just so you can save that 2
> lines to define a class.
>
> class DictModel(models.Model):
>    class Meta:
>        abstract = True
>        ordering = ['value']
>        unique_together = ('value',)
>
>    def __unicode__(self):
>        return unicode(self.value)
>
> # just 2 lines per dictionary and you have all the flexibility you'll ever 
> need
> class School(DictModel):
>    value = models.CharField(max_length=64)
>
> class Suburb(DictModel):
>    value = models.IntegerField()
>
> Also, by giving your dictionaries an explicit name, they can be easily
> reused. I would probably also make the "value" field a primary_key, so
> that you won't have to make all those joins just to print out
> student's info.
>
>>
>> Simon
>>
>>
>> 2010/1/17 Михаил Лукин 
>>>
>>> Well, the simplest way is making DictionaryField more like CharField,
>>> except that it's values will be stored in separate table. For example
>>> (application name is "hardware", engine is sqlite3), if I define
>>>
>>> class HDD(models.Model):
>>>   form_factor = DictionaryField(max_length=10)
>>>   capacity = models.FloatField()
>>>
>>> there will be 2 tables generated:
>>>
>>> CREATE TABLE "hardware_hdd_form_factor_dict" (
>>>     "id" integer NOT NULL PRIMARY KEY,
>>>     "form_factor" varchar(10) NOT NULL UNIQUE
>>> )
>>> CREATE TABLE "hardware_hdd" (
>>>     "id" integer NOT NULL PRIMARY KEY,
>>>     "form_factor_id" integer NOT NULL REFERENCES
>>> "hardware_hdd_form_factor_dict" ("id"),
>>>     "capacity" real NOT NULL
>>> )
>>>
>>> I guess, field constructor should not accept "unique" argument as it make
>>> no sense.
>>> I see 2 ways of rendering such field on a form:
>>> 1) usual  with 

Re: DB optimization docs

[Russell Keith-Magee]

On Mon, Jan 18, 2010 at 2:03 AM, Mat Clayton  wrote:
> Thrown together a first attempt at adding multi column indexes and just want
> some comments on the syntax used, for example.
> from django.db import models
> class Poll(models.Model):
>     question = models.CharField(max_length=200, db_index=True)
>     pub_date = models.DateTimeField('date published')
>     class Meta:
>         db_index_together = ('id', '-question:1',),
> will create an extra index on the Poll model using
> BEGIN;
> CREATE INDEX `app_poll_question` ON `app_poll` (`question`);
> CREATE INDEX `app_poll_3d2b7686` ON `app_poll` (`id`, `question`(1) DESC);
> COMMIT;
> As you can see I decided to implement the ASC/DESC using the conventional
> '-' sign to indicate a DESC, although MySQL accepts this at the moment, it
> currently is ignored by the parser, but other backends including sqlite3 can
> use it. Also I've gone with syntax which allows the index length to be
> defined. The index name is also a hash of the various fields, preventing it
> from becoming too long.
> What isn't demo'ed here is db_index_together also accepts a tuple or tuple
> of tuple's to match the interface to unique_together.
> Anyone got any comments or feedback on the interface?

I'm not really keen on the :1 syntax. Like I said last time, if you're
serious about database optimization, you don't use the ORM, you do it
by hand. Django provides support for this sort of manual optimization
with initial SQL files. I'd be perfectly happy to just allow full
content indexes for text/char fields, and leave partial indexes as a
hand-optimization activity.

The DESC syntax is almost in the same boat for me, but given that it's
fairly simple to add, and consistent with order_by/ordering, I can
live with it.

> Ive not had time to put together docs/tests yet, but don't expect the doc's
> to take too long. Does anyone have any recommendation on how to approach the
> tests? Can't say i'm big on tests, and not sure where to start with these.

I would suggest that there are two test groups that are requried:

Firstly, error handling. A bad db_index_together definition (e.g.,
referencing a column that doesn't exist) should raise a
ValidationError. You should be able to do this in the invalid_models
test - define a bad model, and check that the validation error is
returned as expected. As an aside, it looks like we're not actually
testing unique_together in this way, so while you're in the area...
:-)

Secondly, that a well defined db_index_together statement will sync,
and doesn't break queries. To do this, create an app with a couple of
tables that have various db_index_together definitions that span the
interesting combinations. Then do some simple queries that should hit
the index. It doesn't really matter what the input is or the results
are - all you're looking to test is that a model with a
db_index_together definition will create tables and not break.

Strictly, this doesn't actually prove that the index is working - a
no-op for index handling would pass the same test - but there isn't
much we can to to validate query plans or table definitions. In this
case, we have to rely on eyeballing that indexes are actually created,
and then rely on the fact that the tests pass as a measure that what
is created is valid.

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

Re: Reservations about "default" database in 1.2 alpha

[Russell Keith-Magee]

On Mon, Jan 18, 2010 at 1:21 AM, Bill Hubauer  wrote:
>
> Hi all,
>
> I'm new to the group, so my apologies if this has been discussed
> already.    I have some serious reservations about the implementation
> of the "default" database in the new multi-db support feature.
>
> Anytime you obtain a model from a given database (with the "using"),
> shouldn't any operation on that model default to the database that it
> *came from*, not the "default" database in the settings file?

As far as I'm aware, that's exactly what should be happening. If you
retrieve an object from 'other', the object should retain an internal
state that indicates that it came from 'other', and subsequent
database operations (including save) should be directed to the 'other'
database.

There are some cases where this shouldn't happen - for example, in a
master/slave setup. I'm tinkering with some code at the moment to
control this sort of database allocation. However, in the trunk code
that currently exists, an object retrieved from 'other' should be
sticky on that database.

> Sometimes the code that calls save on the model doesn't know (and
> shouldn't care) where it came from.   It seems really easy to
> accidentally save a model back to a different database than it came
> from.
>
> Thoughts?

Have you got a specific failing case of example code where this is happening?

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

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

[Yuri Baburov]

Hi Harro,

Just create a special "AnonymousUser" as User with id=0, and set it up
with backend/middleware.
You'll have your permissions.

On Sun, Jan 17, 2010 at 2:45 PM, Harro  wrote:
> Why wouldn't a AnonymousUser have permissions?
>
> Imagine a site where can create photo albums.
>
> User A creates two photo albums, one to share with a specific set of
> users and one that's public.
> So Album A has no guest permissions, Album B has viewing permissions.
> Now let's say you can also comment on and rate a photo. Which are two
> separate things. For some photo's you might want to disable rating and/
> or commenting.
> Now you could go an add can_comment, can_rate booleans on the photo,
> but thats not needed with row level permissions.
>
> I really don't care how or where to store the permissions for
> AnonymousUsers, that's up to the person implementing a backend for it,
> I do care however about that fact that the current implementation is
> limiting the system.
>
>
>
> On Jan 15, 5:27 pm, Anton Bessonov  wrote:
>> No. You need row based permissions if You will limit User(!) rights. For
>> example user can edit entries with FK 2. 
>> Seehttp://code.djangoproject.com/wiki/RowLevelPermissions
>>
>> But AnonymousUser (Guest) don't have any permissions. It's a special and
>> that the guest can - it's not a permission - it's a setting.
>>
>> Gert Van Gool schrieb:
>>
>>
>>
>> > Isn't the idea of row based permission that you don't need a special
>> > model for that?

-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Suggestion: DictionaryField

[Simon Meers]

I had considered designing something like this last week. It does seem to be
a common requirement -- any situation where a simple field would be almost
suitable but for the fact you'd like to avoid duplicates and allow fast
selection of existing values. A Field shortcut could be commonly used to
avoid the creation of separate models. Another example:

class Suburb(models.Model):
name = models.CharField(max_length=64, unique=True)

class Meta:
ordering = ['name']

def __unicode__(self):
return u'%s' % self.name


class School(models.Model):
name = models.CharField(max_length=64, unique=True)

class Meta:
ordering = ['name']

def __unicode__(self):
return u'%s' % self.name


class Student(models.Model):
school = models.ForeignKey(School)
suburb = models.ForeignKey(Suburb)
# ...

could be replaced with simply:

class Student(models.Model):
school = models.DictionaryField(max_length=64)
suburb = models.DictionaryField(max_length=64)
# ...

I'm not 100% sold on the name, but I think it is on the right track. I'm
also wondering whether it could be worth catering for types other than
CharField as well. For example:

team_number = models.DictionaryField(type=models.IntegerField)

This makes me wonder whether perhaps this could be generically applied to
all fields via a Field.__init__ kwarg instead:

class Student(models.Model):
school = models.CharField(max_length=64, lookup=True)
suburb = models.CharField(max_length=64, lookup=True)
team_number = models.IntegerField(lookup=True)

Either way, these fields could then be stored in separate tables
appname_modelname_fieldname, with a single field of the appropriate type
(named 'value' or similar). It would be nice to also provide external access
to these auto-generated models via something like Student.school.objects.
Currently Student.school would be a ReverseSingleRelatedObjectDescriptor,
and objects can be accessed via
Student.school.field.related.parent_model.objects.all(), but a shortcut
would be nice.

The auto-generated models could provide ordering by value, a unique
constraint on the field, and a simple __unicode__ method like the examples
above.

Simon


2010/1/17 Михаил Лукин 

> Well, the simplest way is making DictionaryField more like CharField,
> except that it's values will be stored in separate table. For example
> (application name is "hardware", engine is sqlite3), if I define
>
> *class HDD(models.Model):
>   form_factor = DictionaryField(max_length=10)
>   capacity = models.FloatField()
> *
> there will be 2 tables generated:
>
> *CREATE TABLE "hardware_hdd_form_factor_dict" (
> "id" integer NOT NULL PRIMARY KEY,
> "form_factor" varchar(10) NOT NULL UNIQUE
> )
> CREATE TABLE "hardware_hdd" (
> "id" integer NOT NULL PRIMARY KEY,
> "form_factor_id" integer NOT NULL REFERENCES
> "hardware_hdd_form_factor_dict" ("id"),
> "capacity" real NOT NULL
> )
>
> * I guess, field constructor should not accept "unique" argument as it
> make no sense.
> I see 2 ways of rendering such field on a form:
> 1) usual  with autocompletion;
> 2)  +  + (maybe) radio buttons
> as it should be allowed to choose from existing and to create new
> dictionary item.
>
-- 

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

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

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

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

Re: DB optimization docs

[Mat Clayton]

Thrown together a first attempt at adding multi column indexes and just want
some comments on the syntax used, for example.

from django.db import models

class Poll(models.Model):
question = models.CharField(max_length=200, db_index=True)
pub_date = models.DateTimeField('date published')

class Meta:
db_index_together = ('id', '-question:1',),

will create an extra index on the Poll model using

BEGIN;
CREATE INDEX `app_poll_question` ON `app_poll` (`question`);
CREATE INDEX `app_poll_3d2b7686` ON `app_poll` (`id`, `question`(1) DESC);
COMMIT;

As you can see I decided to implement the ASC/DESC using the conventional
'-' sign to indicate a DESC, although MySQL accepts this at the moment, it
currently is ignored by the parser, but other backends including sqlite3 can
use it. Also I've gone with syntax which allows the index length to be
defined. The index name is also a hash of the various fields, preventing it
from becoming too long.

What isn't demo'ed here is db_index_together also accepts a tuple or tuple
of tuple's to match the interface to unique_together.

Anyone got any comments or feedback on the interface?

Ive not had time to put together docs/tests yet, but don't expect the doc's
to take too long. Does anyone have any recommendation on how to approach the
tests? Can't say i'm big on tests, and not sure where to start with these.

Mat

On Sat, Jan 16, 2010 at 2:03 PM, Russell Keith-Magee  wrote:

> On Sat, Jan 16, 2010 at 9:55 PM, Mat Clayton  wrote:
> > Thanks, I've looked over both sets of code, seem's fine to me. The only
> > complex stuff is that Indexes can only be created on certain field types,
> so
> > additional checks may need doing. Also different index types are
> available
> > on different storage engines, for MySQL. Would people want support for
> > selecting the index type and direction?
>
> I'd say don't bother. If you *really* want to fine tune your database,
> you aren't going to use the ORM - you're going to use initial SQL
> defintions, or leave it up to your handy neighborhood db admin. On top
> of that, anything beyond a simple "CREATE INDEX foo ON bar (attr,
> attr)" is going to start walking into areas that are specific to
> individual databases.
>
> db_index=True has been sufficient for indexes of all types so far; I'm
> happy to continue the trend here.
>
> > Finally char field index lengths need to be considered, I'm assuming the
> > Meta field would have to take these into account as well.
> > Also have reopened a ticket http://code.djangoproject.com/ticket/5805 to
> > cover this
>
> Cheers. I should have known this had been suggested before :-)
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
>
>


-- 
-- 
Matthew Clayton | Founder/CEO
Wakari Limited

twitter http://www.twitter.com/matclayton

email m...@wakari.co.uk
mobile +44 7872007851

skype matclayton
-- 

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

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

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

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

Reservations about "default" database in 1.2 alpha

[Bill Hubauer]

Hi all,

I'm new to the group, so my apologies if this has been discussed
already.I have some serious reservations about the implementation
of the "default" database in the new multi-db support feature.

Anytime you obtain a model from a given database (with the "using"),
shouldn't any operation on that model default to the database that it
*came from*, not the "default" database in the settings file?

Sometimes the code that calls save on the model doesn't know (and
shouldn't care) where it came from.   It seems really easy to
accidentally save a model back to a different database than it came
from.

Thoughts?

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

Re: help needed: non-relational DB support

[Russell Keith-Magee]

On Sun, Jan 17, 2010 at 9:56 PM, Waldemar Kornewald
 wrote:
> On Sun, Jan 17, 2010 at 5:36 AM, Russell Keith-Magee
>  wrote:
>> On Sun, Jan 17, 2010 at 9:37 AM, Waldemar Kornewald
>>  wrote:
>>> On Sat, Jan 16, 2010 at 10:35 PM, flo...@gmail.com  wrote:
 I'm not really a developer on Django itself, but I am fairly
 interested in non-relational databases, and some of the things being
 said in this thread worry me a bit.
>>>
>>> OK, if you read my mail literally I sound like "all" nonrel DBs are
>>> the same. Of course they're not and you can find a counter-example for
>>> almost everything. There's nothing to worry about, though. The
>>> counter-examples simply need additional changes to get supported. It's
>>> not like my changes would prevent other backends.
>>
>> No, but they don't allow other backends either. From my perspective,
>> the purpose of this effort is to make the modifications to core that
>> make *any* backend that stores data possible.
>
> It is, absolutely. I think most (if not all) of the other key-value
> stores need just two additions:
>
> 1. AutoField with string values
>
> 2. Extra backend-specific meta-data in Model
> CouchDB and other versioned backends would store the internal revision
> number and use that on UPDATE, for example.
>
> In my previous mail I already mentioned that probably all nonrel
> backends will need to know the pk column names of all tables in order
> to emulate JOINs and maybe a few other features.
>
> Have I missed anything?

Yes :-)

Like I've said several times now, I'm not focussing on non-SQL
backends at the moment.

I can give you broad guidance as to the type of proposal that we are
likely to accept. My last email was an attempt at such advice (i.e,
your proposal shouldn't be GAE specific).

I can also give you specific advice on specific questions about
Django's architecture.

However, I'm *not* an expert on any particular non-SQL storage
framework. I'm not in a position to give any sort of meaningful advice
on how any particular non-SQL backend will be able to integrate with
any particular architectural proposal. People like Eric are in a much
better position to answer questions like those.

When the 1.3 development cycle starts, I will evaluate the proposals
on the table. And - as I've said before - a proposal isn't "merge this
branch". It also includes enough discussion and description to
convince me (and others) that the solution described by a proposal is
correct.

> As Thomas said, I just wanted to know whether you'd suggest going on
> with our SQLCompiler-based solution and I'd like to know what you
> think about it in general. Or is it too early to say anything?

Honestly, I have no idea. You're the ones that will need to evaluate
if a SQLCompiler-based solution is feasible. Investigate, work out
what complications and limitations exist (for GAE and for other
backends), and report back in the form of a concrete proposal.

If you want my gut reaction, I would suggest that interpreting a
SQL-focussed data structure doesn't strike me as a particularly
workable solution for backends that don't expose a pseudo-SQL
interface.

However, I may also be completely wrong. Your task is to convince me,
the core team, and the rest of Django community that what you have
proposed will be sufficient to solve the problem in the general case.

I will say that I like the simplicity of the SQLCompiler approach -
the QueryData approach of adding yet another layer between Query and
final query language really doesn't appeal to me. However,
architectural simplicity ain't worth a hill of beans if it doesn't do
the job it needs to do.

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

Re: Logging format decision

[Ivan Sagalaev]

Russell Keith-Magee wrote:

You've also defined a production server that uses just two loggers -
exception and info - for the entire server. Again, this isn't
especially realistic - in practice, you have a large number of fine
grained loggers for different parts of the system.


In fact, most of our production services use just two loggers: one for 
exceptions and one for everything else. So that one with maintenance was 
the most interesting :-). But see below...



I think I understand what you're advocating - I just think you've
missed some very important use cases.


And I do understand what you and Vinay are saying. I really don't miss 
those use-cases. I intentionally try to avoid them in practice to not 
complicate things.


But since you both feel that they are indeed important so be it, let's 
make it this way.
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Translation Sprint in Montréal

[Yannick Gingras]

Hello Django Dev, 
  this is just a quick note to let you know that we're going to have a
small translation sprint here in Montréal on Monday:

http://montrealpython.org/2010/01/15/django-translation-sprint-on-2010-01-18/
http://code.djangoproject.com/wiki/Sprint201001Montreal

Best regards,

-- 
Yannick Gingras
http://ygingras.net
http://confoo.ca -- track coordinator
http://montrealpython.org -- lead organizer


signature.asc
Description: This is a digitally signed message part.

Re: help needed: non-relational DB support

[Waldemar Kornewald]

On Sun, Jan 17, 2010 at 5:36 AM, Russell Keith-Magee
 wrote:
> On Sun, Jan 17, 2010 at 9:37 AM, Waldemar Kornewald
>  wrote:
>> On Sat, Jan 16, 2010 at 10:35 PM, flo...@gmail.com  wrote:
>>> I'm not really a developer on Django itself, but I am fairly
>>> interested in non-relational databases, and some of the things being
>>> said in this thread worry me a bit.
>>
>> OK, if you read my mail literally I sound like "all" nonrel DBs are
>> the same. Of course they're not and you can find a counter-example for
>> almost everything. There's nothing to worry about, though. The
>> counter-examples simply need additional changes to get supported. It's
>> not like my changes would prevent other backends.
>
> No, but they don't allow other backends either. From my perspective,
> the purpose of this effort is to make the modifications to core that
> make *any* backend that stores data possible.

It is, absolutely. I think most (if not all) of the other key-value
stores need just two additions:

1. AutoField with string values

2. Extra backend-specific meta-data in Model
CouchDB and other versioned backends would store the internal revision
number and use that on UPDATE, for example.

In my previous mail I already mentioned that probably all nonrel
backends will need to know the pk column names of all tables in order
to emulate JOINs and maybe a few other features.

Have I missed anything?

As Thomas said, I just wanted to know whether you'd suggest going on
with our SQLCompiler-based solution and I'd like to know what you
think about it in general. Or is it too early to say anything?

Bye,
Waldemar Kornewald

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

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

[Anton Bessonov]

Why wouldn't a AnonymousUser have permissions?
  

Basically, this is senseless.

For some photo's you might want to disable rating and/
or commenting.
  
How often it is required to the user? In 99% of cases it is enough 
specify in an album "can" or "can not". It's really overkill of features.

Now you could go an add can_comment, can_rate booleans on the photo,
but thats not needed with row level permissions.
  
The subject is "AnonymousUser has_perm/has_module_perms [...]" and it 
has not something in common with the row level permission support. It's 
are two separate things.

I really don't care how or where to store the permissions for
AnonymousUsers, that's up to the person implementing a backend for it,
I do care however about that fact that the current implementation is
limiting the system.
Django's right management is basic and common. This is designed for 
"most apps".
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: help needed: non-relational DB support

[Thomas Wanschik]

On 17 Jan., 05:36, Russell Keith-Magee  wrote:
> On Sun, Jan 17, 2010 at 9:37 AM, Waldemar Kornewald
>
>  wrote:
> > On Sat, Jan 16, 2010 at 10:35 PM, flo...@gmail.com  wrote:
> >> I'm not really a developer on Django itself, but I am fairly
> >> interested in non-relational databases, and some of the things being
> >> said in this thread worry me a bit.
>
> > OK, if you read my mail literally I sound like "all" nonrel DBs are
> > the same. Of course they're not and you can find a counter-example for
> > almost everything. There's nothing to worry about, though. The
> > counter-examples simply need additional changes to get supported. It's
> > not like my changes would prevent other backends.
>
> No, but they don't allow other backends either. From my perspective,
> the purpose of this effort is to make the modifications to core that
> make *any* backend that stores data possible.

The current patch does not prevent any other backend, neither
relationl nor non-relational ones, to be implemented. As Waldemar
wrote we only added flags currently, such that each backend can decide
itself if a set of features is supported or not. Databases like Riak
and CouchDB which explicitly distinguish between insert and update can
do it with the current modification too. In this sense the current
patch should work for all non-relational databases and nothing is App
Engine specific.

>
> >> I think these efforts are great--a lot of people want to get up and
> >> running on GAE with Django, and it's not so easy right now.  It just
> >> worries me a bit that the description of the effort encompasses all of
> >> non-relational databases when the implementation seems to primarily
> >> reason around GAE.  It makes sense to concretely pick one database and
> >> start there, otherwise no work would ever be finished, but I think
> >> that the better thing to do is to call it GAE support instead of
> >> nonrel support.
>
> > We have people interested in adding MongoDB, CouchDB, and maybe
> > SimpleDB support. The current code should be abstract enough for
> > SimpleDB and probably also MongoDB (though, it would help to modify
> > AutoField to also support string values). Other DBs might need
> > additional changes, but that's what the "nonrel" project is for.
> > Everyone can join and work on Django changes needed for their DB.
>
> We need to be clear about your goals here.
>
> Speaking for me personally, It's going to be very hard to get me to be
> interested in this project unless you're trying to solve the whole
> problem.
>
> We have a backend interface that works well for SQL. I'm interested in
> seeing the set of modifications that are required in break the
> SQL-specific aspects of that interface.
>
> I'm not at all interested in spending a bunch of time vetting
> modifications that only solve part of the problem - especially when
> those modifications may well prevent the elegant introduction of a
> fully refactored backend interface.
>
> I have no problems with the idea of tackling this problem in an
> iterative fashion (i.e., get it working for GAE, then get it working
> for GAE+MongoDB, and so on), but I'm not going to commit anything to
> trunk until you've got enough backends (with enough breadth of
> features) to demonstrate that the refactoring that you propose is
> sufficient to solve the general problem.

The main question of Waldemar was which proposal to follow (using
QueryData or the current compiler approach introduced by mutli-db) and
nobody answered! It seems that multi-db support made a good step
towards even supporting non-relational databases. Such databases can
use a compiler which can interpret SQL.Query. We thing that only minor
modifications are needed to be completly SQL independent and to be
abstract enough for non-relational databases. Following the QueryData
proposal will most probably lead to copy 95% of SQL.Query. So we think
that following the second approch is much better. But we need
feedback!
So we are asking for feedback in order to prevent ourself from
following the wrong proposal.
Again this is not the final patch and other changes will surely be
added.

Bye,
Thomas Wanschik

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

Re: Logging format decision

[Russell Keith-Magee]

On Sun, Jan 17, 2010 at 5:17 AM, Ivan Sagalaev
 wrote:
> Russell Keith-Magee wrote:
>>
>> That said - I really do want to see logging in Django's trunk. If we
>> can sort out the details in the background and get a good
>> implementation ready, it could easily be the first feature committed
>> for v1.3.
>
> Agreed!
>
>> I like Vinay's suggestion for exactly the reason you dislike it. The
>> definition of a handler is independent of the loggers that use that
>> handler. Simon's example in (4) hides a lot of details behind ellipses
>> - if you expand those ellipses, you discover that there is a lot of
>> repeated typing of '/tmp/django-sql.log' etc if you want all your logs
>> to appear in the same file. Under Vinay's proposal, you define a
>> single file log handler, and instruct each of the loggers to use that
>> handler.
>
> Actually, I don't see this problem of repetition that you're describing so I
> thought that we could use some examples closer to real world to sort this
> out. May be I just don't see something obvious to you or have misunderstood
> Vinay's schema. I will refer to two formats we're discussing as "explicit
> handlers" (Vinay's) and "implicit handlers" (what Simon has implemented).
> Better suggestions for naming are welcome :-).
>
> 1. The first use-case is the development environment where all you want is
> everything logged in one file with DEBUG level.
>
> "Implicit handlers":
>
>    LOGGING = {
>        '': {
>            'handler': 'django.logging.FileLogger',
>            'filename': '/home/user/myproject/all.log',
>            'level': 'debug',
>        },
>    }
>
> "Explicit handlers":
>
>    LOGGING = {
>        'formatters': {
>            'all': '%(asctime)s %(name)-15s %(levelname)-8s %(message)s',
>        },
>        'handlers': {
>            'all': {
>                'class': 'django.logging.FileLogger',
>                'filename': '/home/user/myproject/all.log',
>                'formatter': 'all',
>                'level': 'debug',
>            },
>        },
>        'loggers': {
>            '': {
>                'handlers': ['all'],
>            },
>        },
>    }
>
> 2. A production environment. This actually what we have for one of our
> services:
>
> - a file for uncaught server errors that are logged by a function listening
> to `got_request_exception` signal which uses 'exception' label to log
> - a file for maintenance messages that come from cron scripts that all use
> 'maintenance.*' labels to log
> - a file for everything else
>
> "Implicit handlers":
>
>    _log_path = '/var/log/service/'
>
>    LOGGING = {
>        'exception': {
>            'handler': 'django.logging.FileLogger',
>            'filename': _log_path + 'exception.log',
>            'format': '%(asctime)s %(levelname)-8s %(message)s',
>            'level': 'warning',
>            'propagate': False,
>        },
>        'maintenance': {
>            'handler': 'django.logging.FileLogger',
>            'filename': _log_path + 'maintenance.log',
>            'format': '%(asctime)s %(name)-15s %(levelname)-8s %(message)s',
>            'level': 'info',
>            'propagate': False,
>        },
>        '': {
>            'handler': 'django.logging.FileLogger',
>            'filename': _log_path + 'info.log',
>            'format': '%(asctime)s %(name)-15s %(levelname)-8s %(message)s',
>            'level': 'info',
>        },
>    }
>
> (Note: "propagate" is not implemented right now in Simon's code but is quite
> easy to add).
>
> "Explicit handlers":
>
>    _log_path = '/var/log/service/'
>
>    LOGGING = {
>        'formatters': {
>            'exception': '%(asctime)s %(levelname)-8s %(message)s',
>            'default': '%(asctime)s %(name)-15s %(levelname)-8s %(message)s',
>        },
>        'handlers': {
>            'exception': {
>                'class': 'django.logging.FileLogger',
>                'filename': _log_path + 'exception.log',
>                'formatter': 'exception',
>                'level': 'warning',
>            },
>            'maintenance': {
>                'class': 'django.logging.FileLogger',
>                'filename': _log_path + 'maintenance.log',
>                'formatter': 'default',
>                'level': 'info',
>            },
>            'info': {
>                'class': 'django.logging.FileLogger',
>                'filename': _log_path + 'info.log',
>                'formatter': 'default',
>                'level': 'info',
>            }
>        },
>        'loggers': {
>            'exception': {'handlers': ['exception'], 'propagate': False},
>            'maintenance': {'handlers': ['maintenance'], 'propagate': False},
>            '': {'handlers': ['info']},
>        },
>    }
>
> In both examples "implicit handlers" give shorter code and, to me, are more
> readable.

I can't argue that your version is shorter - but the terseness is only
possible because of the example that you have chosen (and 

Re: Logging format decision

[Vinay Sajip]

On Jan 16, 9:17 pm, Ivan Sagalaev  wrote:
> The main point that I'm trying to argue is that having handlers and
> loggers *separate* is not needed in real world scenarios. If you want
> your logging in several files you will have to define several handlers
> and several loggers anyway. "Implicit handlers" format accept this fact
> and couples both handler and logger definitions in one place.

I don't agree with your statement that  "having handlers and loggers
separate is not needed in real world scenarios". Maybe in your
experience you haven't needed it, but I certainly have on more than
one occasion. What I've found is that everyone's logging needs are
different, and the rationale for having handlers and loggers as
separate concepts is described in

http://plumberjack.blogspot.com/2009/09/python-logging-101.html

> I understand this point. This is why I'm going to argue for "implicit
> handlers" just to the point when I see that I made myself clear, not
> until everyone agrees with me :-). May be consistency here is more
> important than convenience.
>
> However, may be we can work out a format that suit both parties. What I

Well, I believe I've already covered this in PEP 391:

http://www.python.org/dev/peps/pep-0391/#user-defined-objects

You can instantiate stuff either using the default schema or use your
own factories to construct the logging objects you need. I would say,
if a simplifying layer is needed, it can be built on top of the
proposed PEP 391 changes, and perhaps some usage patterns would become
apparent over time to be so common as to justify putting in the core.
Although the PEP refers to "user-defined objects", you can use a
factory to instantiate any logging object, including instances of
existing logging classes.

And, don't forget the Zen of Python - "Explicit is better than
implicit" ;-)

Regards,

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

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

[Harro]

Why wouldn't a AnonymousUser have permissions?

Imagine a site where can create photo albums.

User A creates two photo albums, one to share with a specific set of
users and one that's public.
So Album A has no guest permissions, Album B has viewing permissions.
Now let's say you can also comment on and rate a photo. Which are two
separate things. For some photo's you might want to disable rating and/
or commenting.
Now you could go an add can_comment, can_rate booleans on the photo,
but thats not needed with row level permissions.

I really don't care how or where to store the permissions for
AnonymousUsers, that's up to the person implementing a backend for it,
I do care however about that fact that the current implementation is
limiting the system.



On Jan 15, 5:27 pm, Anton Bessonov  wrote:
> No. You need row based permissions if You will limit User(!) rights. For
> example user can edit entries with FK 2. 
> Seehttp://code.djangoproject.com/wiki/RowLevelPermissions
>
> But AnonymousUser (Guest) don't have any permissions. It's a special and
> that the guest can - it's not a permission - it's a setting.
>
> Gert Van Gool schrieb:
>
>
>
> > Isn't the idea of row based permission that you don't need a special
> > model for that?
>
> > -- Gert
>
> > Mobile: +32 498725202
> > Web:http://gert.selentic.net
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.