[GSoC] Customizable Serialization Proposal

[DaNmarner]

First of all: my native language is not English, so I apologize for
any potential natural language error (or any error at all) below.

After (briefly) reading through the current implementaion as well as
the "Issues to consider" section in the GSoC2011 page on wiki, my
initial observation is that the current code structure/abstraction is
almost good enough to cater all the "Issues" on the wiki if The need
for "Serializing non-database attributes/properties" is not considered
for now.

It seems to me that an simple enhancement on the configuration options
of the current serializer would suffice a lot of the needs here. The
best approch I thought of so far is adding a configuration object to
the parameter. It contains infomation about what modification needs to
be done during the serialization. Does any field name needs to be
mapped to a different one? How many levels to go as far as foreign key
is concerned? What are the unnecessary fields (of course, the current
"fields" option would fit well in here, too)?  What are the relations
between two fields in the result?

This configuration object will be available to all the
subclass-serializers for different format all the time, so that
everytime a field is being serialized, the serializer will look for
infomation the configuration object recarding this field.

Further, when a fk is encountered, the configuration can contain
reference to another configuration object, which, if desired (level of
serialization not yet reached), will be used to serialize the object
fk refers to.

Naturally, the configuration object should be defined with classes (I
almost wanted to call it Meta, as in the Models).

I feel like I'm still missing a lot to consider. I'm aware of the old
proposals in the past and I'm planning to digest those as soon as
possible. But I really want to hear thoughts about my idea from
y'all. So please, tell me what's wrong in it.

PS: I have about 3 years Python experience, big Django fan, sort of a
user (wrote my own blog, of course), my ID has appeared in Django
commit msgs for about 3 times so far :).

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Customizable Serialization

[Vivek Narayanan]

> I also haven't seen any proposals or examples of how I'd use the API as
> an end user - are people going to be able to register serialisers to
> models (since they're apparently tied to specific models anyway)?

There will be different types of serializers like JSONSerializer,
YAMLSerializer, XMLSerializer etc . The end users will have to
subclass these, just like creating a new model.
While they need not be tied to specific models and can be used as
'generic' serializers, its finally down to the user's choice.


> I'm unclear about what meta2_ accomplishes - is it for things that are
> not fields, but still serialisable? Surely there's a better way to go
> about this?

It is for meta data of whole models (those implemented in the database
as "tables" and go through the start_model -> end_model cycle in the
current implementation of the serializer), basically a collection of
other fields, I believe the word 'model' is quite ambiguous in this
context. If there is a meta2_name method defined , the output would be
like this.

{
   "name": " Output of meta2_name() here ",
   ... # fields of the model follow
}

> > An extras argument, which would allow properties and data returned
> > by some methods to be serialized.
>
> How, exactly? What do you pass in this argument?

The extras option allows the user to serialize properties of a model
that are not fields. These properties may be almost any standard
python attribute or method. Say, there is a model , Article, defined
like this:

class Article(models.Model):
headline = models.CharField(maxlength=100, default='Default
headline')
contents = models.TextField()
pub_date = models.DateTimeField()
...
def get_permalink():
  #return some absolute URL



Eg: serialize(queryset, extras = ('Article.get_permalink') )

It takes an an iterable of strings in the format
"Object_Type.method_or_attribute_name".


>
> > -
> > Representing the existing serialization model
> > -
> > Here is an implementation of the existing serialization format in
> > JSON, this would be the fixture mode that I ve mentioned above.
>
> Presumably you're planning to leave the existing fixture-loading code as
> it currently is, given that there's no mention of it here? Are the
> customisable serialisers purely for use by other, non-Django
> applications in your plan?

I would be leaving most of the existing fixture loading code intact
but add support for deserializing fixtures in an arbitrary format.
These fixtures should contain some minimum required data for
generating the model like content type, required fields etc.


> How about if I just want to customise how the serialiser outputs
> DateTimeFields, or tell it how to serialise my new, shiny, custom field
> - does your proposal have any way to override things on a field type basis?

The data in the fields can be retrieved in the form of a python object
using the to_python method of the field as described here (
http://docs.djangoproject.com/en/dev/howto/custom-model-fields/ ). In
the case of the DateTimeField, it will be a datetime.datetime object.
Now, this is where the 'unicode_' methods come into play. By defining
a method "unicode_datetime_datetime()" in the serialiser , the
serialisation process for DateTimeFields  can be overridden. The same
holds good for custom fields. If this naming convention based on the
python type is confusing, I can implement it according to the Django
field type.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Enhanced auth.User

[Russell Keith-Magee]

On Wed, Mar 23, 2011 at 10:21 AM, crodjer  wrote:
> On Wednesday, March 23, 2011 5:10:36 AM UTC+5:30, Russell Keith-Magee wrote:
>>
>> On Wed, Mar 23, 2011 at 4:32 AM, Rohan Jain  wrote:
>> > These are some auth settings and models I propose to account for the
>> > generally
>> > raised questions for auth.User flexibility.
>>
>> Two quick points:
>>
>> Firstly -- the fact that you've given some biographical detail at the
>> bottom, and that this biographical detail says your a student,
>> suggests that this is a GSoC proposal? Is this the case? If so --
>> that's a pretty big detail to omit. Django-developers is a general
>> list for discussing the development of Django; if you're proposing a
>> GSoC project, you need say so.
>
> This was not a gsoc proposal, I added my biographical details as
> an introduction as this was one of my first post on the group. The
> changes I suggested have been on my mind for some time, so I thought
> of posting it. Auth user model modifications, Dynamic site ID are some
> discussions which have been highly requested and discussed. So I am
> aware that one cannot just write a few modifications and fix it for all.

Understood - in which case, scratch my first comment.

However, my second point stands. This proposal doesn't reference any
of the prior discussion related to this topic, or address any of the
issues that those prior discussions have raised. In the case of
suggesting migrations, it specifically violates a design consideration
that has been repeatedly stated in the past.

I agree that this is definitely a pain point that many people have
with Django, and it is something that I'm hoping to look at in the 1.4
development cycle. If you want to help out, I suggest you familiarize
yourself with the historical discussion.

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-developers@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: Enhanced auth.User

[crodjer]

On Wednesday, March 23, 2011 5:10:36 AM UTC+5:30, Russell Keith-Magee wrote:
>
> On Wed, Mar 23, 2011 at 4:32 AM, Rohan Jain  wrote:
> > These are some auth settings and models I propose to account for the
> > generally
> > raised questions for auth.User flexibility.
>
> Two quick points:
>
> Firstly -- the fact that you've given some biographical detail at the
> bottom, and that this biographical detail says your a student,
> suggests that this is a GSoC proposal? Is this the case? If so --
> that's a pretty big detail to omit. Django-developers is a general
> list for discussing the development of Django; if you're proposing a
> GSoC project, you need say so.
>
This was not a gsoc proposal, I added my biographical details as 
an introduction as this was one of my first post on the group. The 
changes I suggested have been on my mind for some time, so I thought
of posting it. Auth user model modifications, Dynamic site ID are some 
discussions which have been highly requested and discussed. So I am 
aware that one cannot just write a few modifications and fix it for all.  

> Secondly -- This is a reason that this project is listed as a high
> complexity project on the GSoC wiki page. It's deceptively difficult,
> and there's *lots* of prior art. A proposal that starts with
> introducing 3 new settings, and finishes with the phrase "create a
> datamigration script" is essentially a non-starter for reasons that
> are well documented historically.
>
> If you're interested in this project, I *strongly* suggest that you
> spend a couple of days familiarizing yourself with the historical
> discussions about the idea. There was a lengthy discussion around last
> year's GSoC; a student was proposing work on this project, but
> ultimately backed out because of the complexities involved. At the
> very least, it should give an indication of what will and won't be
> accepted.
>
> 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-developers@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: Enhanced auth.User

[Gabriel Hurley]

I would further add that the goal of any refactor in this area is not to add 
a wishlist of enhancements to the existing User model (though that may 
happen in tandem), but to truly make the framework extensible/agnostic in a 
way which it currently is not.

All the best,

- Gabriel

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Enhanced auth.User

[Russell Keith-Magee]

On Wed, Mar 23, 2011 at 4:32 AM, Rohan Jain  wrote:
> These are some auth settings and models I propose to account for the
> generally
> raised questions for auth.User flexibility.

Two quick points:

Firstly -- the fact that you've given some biographical detail at the
bottom, and that this biographical detail says your a student,
suggests that this is a GSoC proposal? Is this the case? If so --
that's a pretty big detail to omit. Django-developers is a general
list for discussing the development of Django; if you're proposing a
GSoC project, you need say so.

Secondly -- This is a reason that this project is listed as a high
complexity project on the GSoC wiki page. It's deceptively difficult,
and there's *lots* of prior art. A proposal that starts with
introducing 3 new settings, and finishes with the phrase "create a
datamigration script" is essentially a non-starter for reasons that
are well documented historically.

If you're interested in this project, I *strongly* suggest that you
spend a couple of days familiarizing yourself with the historical
discussions about the idea. There was a lengthy discussion around last
year's GSoC; a student was proposing work on this project, but
ultimately backed out because of the complexities involved. At the
very least, it should give an indication of what will and won't be
accepted.

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-developers@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: secret key from file...

[Ian Kelly]

On Tue, Mar 22, 2011 at 5:17 PM, Carl Meyer  wrote:
> Interesting. I would have assumed that the reason is so that code in
> site_settings.py has access to the previously defined values in the main
> settings.py, and can actually modify them (i.e. append to
> MIDDLEWARE_CLASSES or whatnot). With an import this is not possible.

That's a good reason too.  It didn't occur to me because we don't
actually do that, and I'm having a hard time envisioning a scenario
where we might want to.  It's good that it's not outside the realm of
possibility, though.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: secret key from file...

[Chris Church]

I've used the execfile approach in my settings.py like so:

# Include any local settings that override the defaults.
try:
execfile('local_settings.py')
# Hack so that the autoreload will detect changes to local_settings.py.
class dummymodule(str):
__file__ = property(lambda self: self)
sys.modules['local_settings'] = dummymodule('local_settings.py')
except IOError:
pass


The advantage of execfile over an import is that the local_settings is
executed within the settings.py namespace, so your local_settings.py can
read or modify default/global settings (add its own middleware, installed
apps, etc).

That all being said, I think it's best left to each project or team or
developer to decide how to make settings.py work for them and hide any
sensitive information.


On Tue, Mar 22, 2011 at 7:09 PM, Matt Robenolt wrote:

> That's just interesting. I've never seen the use of `execfile()` before. We
> use a devsettings.py and use it to override an individual server or local
> settings, and then on the live/deployed server, no devsettings.py is even
> included. Hence the try...except wrapped around it. It's a nice little
> pattern that gets us by, but yes, things like this do show that there needs
> to be one overall "recommended" method for maintaining separate settings on
> a per server/environment basis.
>
> On Mar 22, 2011, at 7:05 PM, Ian Kelly wrote:
>
> > On Tue, Mar 22, 2011 at 4:49 PM, Matt Robenolt
> >  wrote:
> >> Why not just do an import for your custom settings?
> >>
> >> try:
> >>from site_settings import *
> >> except ImportError:
> >>pass
> >
> > No particularly compelling reason that I know of, the import machinery
> > is just unnecessary in this case.  The site_settings.py is viewed as
> > an extension of the settings.py, so it doesn't need to be loaded as a
> > module in its own right.  And for the same reason we know exactly
> > where we expect the file to be, so there's no need to consult
> > sys.path.
> >
> > I suppose it just comes down to a matter of taste.
> >
> > Cheers,
> > Ian
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> > To post to this group, send email to django-developers@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.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: secret key from file...

[Carl Meyer]

On 03/22/2011 07:05 PM, Ian Kelly wrote:
> On Tue, Mar 22, 2011 at 4:49 PM, Matt Robenolt
>  wrote:
>> Why not just do an import for your custom settings?
>>
>> try:
>>from site_settings import *
>> except ImportError:
>>pass
> 
> No particularly compelling reason that I know of, the import machinery
> is just unnecessary in this case.  The site_settings.py is viewed as
> an extension of the settings.py, so it doesn't need to be loaded as a
> module in its own right.  And for the same reason we know exactly
> where we expect the file to be, so there's no need to consult
> sys.path.
> 
> I suppose it just comes down to a matter of taste.

Interesting. I would have assumed that the reason is so that code in
site_settings.py has access to the previously defined values in the main
settings.py, and can actually modify them (i.e. append to
MIDDLEWARE_CLASSES or whatnot). With an import this is not possible.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: secret key from file...

[Matt Robenolt]

That's just interesting. I've never seen the use of `execfile()` before. We use 
a devsettings.py and use it to override an individual server or local settings, 
and then on the live/deployed server, no devsettings.py is even included. Hence 
the try...except wrapped around it. It's a nice little pattern that gets us by, 
but yes, things like this do show that there needs to be one overall 
"recommended" method for maintaining separate settings on a per 
server/environment basis.

On Mar 22, 2011, at 7:05 PM, Ian Kelly wrote:

> On Tue, Mar 22, 2011 at 4:49 PM, Matt Robenolt
>  wrote:
>> Why not just do an import for your custom settings?
>> 
>> try:
>>from site_settings import *
>> except ImportError:
>>pass
> 
> No particularly compelling reason that I know of, the import machinery
> is just unnecessary in this case.  The site_settings.py is viewed as
> an extension of the settings.py, so it doesn't need to be loaded as a
> module in its own right.  And for the same reason we know exactly
> where we expect the file to be, so there's no need to consult
> sys.path.
> 
> I suppose it just comes down to a matter of taste.
> 
> Cheers,
> Ian
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@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.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: secret key from file...

[Ian Kelly]

On Tue, Mar 22, 2011 at 4:49 PM, Matt Robenolt
 wrote:
> Why not just do an import for your custom settings?
>
> try:
>        from site_settings import *
> except ImportError:
>        pass

No particularly compelling reason that I know of, the import machinery
is just unnecessary in this case.  The site_settings.py is viewed as
an extension of the settings.py, so it doesn't need to be loaded as a
module in its own right.  And for the same reason we know exactly
where we expect the file to be, so there's no need to consult
sys.path.

I suppose it just comes down to a matter of taste.

Cheers,
Ian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: secret key from file...

[Matt Robenolt]

Why not just do an import for your custom settings?

try:
from site_settings import *
except ImportError:
pass


On Mar 22, 2011, at 5:51 PM, Ian Kelly wrote:

> On Tue, Mar 22, 2011 at 6:44 AM, Kristaps Kūlis
>  wrote:
>>  I personally would greatly appreciate update in docs to show "best
>> way" to handle per enviroment settings / sensitive settings, as now
>> there is many ways :)
>>  Consider when one has his local development enviroment with locmem
>> cache and sqlite3 db, and staging server with MySQL / memcache and
>> production cluster with MySQL (different credentials) and memcache
>> cluster. In settings.py most deployment  specific stuff is left blank
>> and on deployment {staging/production}_settings.py is created with
>> from settings import * and then overriding per env settings :).
>>  Actually it took me far too much googling to find "how" and "what" to
>> do, at least I believe that such stuff should be put in docs to make
>> django more sysadmin friendly.
> 
> I don't know what the best way is, but I will share what we do.  In
> addition to the regular settings.py we have site_settings.py (which is
> not under version control) in the same directory.  Then at the end of
> settings.py we add this simple code:
> 
> # Run a separate python file not in version control for database
> # settings and other sensitive information.
> from os.path import dirname, join
> execfile(join(dirname(__file__), 'site_settings.py'))
> 
> Cheers,
> Ian
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@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.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: secret key from file...

[Ian Kelly]

On Tue, Mar 22, 2011 at 6:44 AM, Kristaps Kūlis
 wrote:
>  I personally would greatly appreciate update in docs to show "best
> way" to handle per enviroment settings / sensitive settings, as now
> there is many ways :)
>  Consider when one has his local development enviroment with locmem
> cache and sqlite3 db, and staging server with MySQL / memcache and
> production cluster with MySQL (different credentials) and memcache
> cluster. In settings.py most deployment  specific stuff is left blank
> and on deployment {staging/production}_settings.py is created with
> from settings import * and then overriding per env settings :).
>  Actually it took me far too much googling to find "how" and "what" to
> do, at least I believe that such stuff should be put in docs to make
> django more sysadmin friendly.

I don't know what the best way is, but I will share what we do.  In
addition to the regular settings.py we have site_settings.py (which is
not under version control) in the same directory.  Then at the end of
settings.py we add this simple code:

# Run a separate python file not in version control for database
# settings and other sensitive information.
from os.path import dirname, join
execfile(join(dirname(__file__), 'site_settings.py'))

Cheers,
Ian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: secret key from file...

[Paul McMillan]

I would be in support of a manage.py command to change the secret key,
just as a convenience. I'd be happy to implement it.

Matthew Roy said:
> If I understand
> how it works the compromise of the SECRET_KEY alone doesn't put you in
> serious hot water unless the attacker can also intercept traffic.

The SECRET_KEY is secret for a number of very good reasons, and
compromise of it is quite likely to lead to compromise of your
application if the attacker is sufficiently motivated.

-Paul

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: State of X-Sendfile support?

[Paul McMillan]

It's worth pointing out that manage.py runserver isn't likely to ever
support serving those files even if the header arrives in core. It's
explicitly not appropriate for any kind of production use, fallback or
otherwise. If you really need support for your development work (and
checking the headers on the response isn't good enough), you should be
developing in an environment closer to your production server.

I would be very much -1 to any proposal to include code that actually
served the file in django core if the webserver doesn't support
X-Sendfile.

That said, I'd very much like to see support for the header in core.
It's commonly used, and reimplementing it every time is silly.

-Paul

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: [GSoC Proposal] Customizable Serialization

[Andrew Godwin]

On 17/03/11 07:47, Vivek Narayanan wrote:
> Hi,
>
> This is my proposal for the customizable serialization idea:

Hi Vivek - sorry about the long reply-wait on this! My initial thoughts
are below.

> The user can define methods beginning with “meta_” to add metadata
> about each field. And functions starting with “meta2_” can be used to
> add metadata at the model level. Here is an example:
>
> ...
>
> The existing implementation of ``model.name`` and ``model.pk`` can be
> described using “meta2_” functions. These will be provided as
> ``meta2_name`` and ``meta2_pk`` to facilitate loading and dumping of
> fixtures.

I'm unclear about what meta2_ accomplishes - is it for things that are
not fields, but still serialisable? Surely there's a better way to go
about this?

> Permission Framework
> =
> While creating an API, there may arise a need to give varying levels
> of access to data to different people. For this I propose a permission
> framework, where the user can choose to restrict data to certain
> groups while defining a model.

I'm not entirely sure this is something that should be in the same scope
as the main project - adding user permissions into a serialisation
framework feels a bit ugly, especially when it's relatively easy for
people to implement themselves (with the exclude arguments, etc)

> • An extras argument, which would allow properties and data returned
> by some methods to be serialized.

How, exactly? What do you pass in this argument?

> -
> Representing the existing serialization model
> -
> Here is an implementation of the existing serialization format in
> JSON, this would be the ‘fixture’ mode that I’ve mentioned above.

Presumably you're planning to leave the existing fixture-loading code as
it currently is, given that there's no mention of it here? Are the
customisable serialisers purely for use by other, non-Django
applications in your plan?

> ===
> Deliverables and Timeline
> ===
>
> I would be working for about 40-45 hours each week and I would be
> writing tests, exceptions and error messages along with development.
> This would more or less be my timeline:
>

Are you really going to be able to commit 40-45 hours a week? That's a
significant commitment, and more than many full-time jobs (in addition,
I don't see this being 400 man-hours' worth of work - not that that's a
bad thing, we'd rather it was less, as that's a lot of work to commit to)

I also haven't seen any proposals or examples of how I'd use the API as
an end user - are people going to be able to register serialisers to
models (since they're apparently tied to specific models anyway)?

How about if I just want to customise how the serialiser outputs
DateTimeFields, or tell it how to serialise my new, shiny, custom field
- does your proposal have any way to override things on a field type basis?

Those are my initial reactions on the first reading of the proposal with
your change to authentication added in - don't take any criticism too
harshly, we just have to be thorough.

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

Enhanced auth.User

[Rohan Jain]

These are some auth settings and models I propose to account for the 
generally
raised questions for auth.User flexibility.

Settings: 

 - AUTH_USER_EMAIL_UNIQUE  
   If the email should be unique for users. It is a rare case when a website
   would have users sharing emails. It is more likely other way round that a 
user
   has multiple emails.

 - AUTH_USERNAME_MIN_LENGTH/AUTH_USERNAME_MAX_LENGTH  
   Min and max lengths of the username field. 

 - AUTH_USE_OLD_USER_MODLE  
   If the old style (fn-ln based) user model should be used. Maybe a 
deprication
   warning can be provided when this is set to True.

Models: 

 - BaseUser Model ~ Current User Model, abstract  
   There will be a base model with all the same fields as current user model 
but
   not the first_name and last_name fields. 

 - UNIQUE_EMAIL = getattr(settings,'AUTH_USER_EMAIL_UNIQUE', False)  
   email = EmailField(blank=not UNIQUE_EMAIL, unique=UNIQUE_EMAIL)  
   email column unique/no unique according to AUTH_USER_EMAIL_UNIQUE 
setting. 

 - A method can be defined which could generate random username while 
registering
   if required, like in case of logging in with email, openid, oauth etc. 
   
 - Provision for authentication through email id can easily be provided if
   UNIQUE_EMAIL is set. 
 
 - EnhancedUser, abstract  
   Inherits from BaseUser.  
   Have a field `name` instead of old `first_name`, `last_name`. A single 
field 
   for name is preferable as it would be more comfortable to users and would 
also 
   take care of case when the User model doesn't represents an individual 
but may 
   be a team, an organization etc.  
   Also a text field `description/about` could be provided as it is 
generally 
   present in basic user profiles everywhere. This would prevent necessity 
to use 
   a separate Profile model.  
   These fields would result in some minor changes in places like 
auth.models and
   auth.admin. The first_name and last_name fields are generally accessed 
through
   get_full_name method which could be redefined to return `name`.

 - OldUser, abstract  
   This with BaseUser will generate the current User model with 
`first_name`,
   `last_name` fields and the get_full_name method. In case of an old 
project, with
   large database, upgrading to newer django versions.

 - User  
   This would inherit from EnhancedUser or OldUser according to the 
AUTH_USE_OLD_USER_MODLE
   setting and will be the model exposed to other apps, hence there should 
not be
   any compatibility issues.

Now as far as old projects upgradation to new User model is concerned, that
could be done with the help of application 'south'. A migration scripts can 
be
written:

 1. Create a column `name`. 
 2. Create datamigration script to copy `first_name` + `last_name` to 
`name`. 
 3. Drop `first_name` and `last_name` column. 


About Me:  
I am a 3rd year Engineering undergraduate student from the Department of
Agricultural and Food Engineering, Indian Institue of Technology, Kharagpur. 
I
have been using django for a year now and recently started working with the 
SVN
version, hacking the codes of contrib apps and trying to learn the best
practices.  
Website: http://www.rohanjain.in
GitHub: http://github.com/crodjer

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: type error couldn't able to point it

[Jirka Vejrazka]

2 more comments ( I just noticed ):

 - these questions should be sent to django-users, not django-developers

 - why go through all stock values to find the best one in the loop
(you could use agregates for that) and then only return count?

  Cheers

Jirka

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: type error couldn't able to point it

[Jirka Vejrazka]

Hi there,

 I have not used this myself, but believe that "Q objects" don't
support & operator as you use it. So it's really a Python error, not
Django error.

FYI, you need Q objects only to provide "OR" functionality. For "AND"
functionality, you only need:

mu1 = MarketUpdate.objects.filter(stock_symbol=ticker,
update_timestamp__gt=test_start_date).order_by('stock_value')

  HTH

Jirka

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

type error couldn't able to point it

[NavaTux]

This is my django snippet to calculate custome stmts but it displays
the error
from optionsAlpha.models import MarketUpdate
from datetime import datetime
from django.db.models import Q

def stock_up(ticker, test_start_date):
#stock_value=0
mu1 = MarketUpdate.objects.filter(Q(stock_symbol=ticker) &
Q(update_timestamp__gt=(test_start_date))).order_by('stock_value')
#print mu1[0].stock_value
max_stock=mu1[0].stock_value
count=0
for i in mu1:
 if i.stock_value >= max_stock:
 max_stock = i.stock_value
 count+=1
return count


Output when calling this method from django shell:

>>> dat
datetime.datetime(2011, 3, 19, 8, 58, 28, 999615)
>>> ticker
'GOOG'
>>> stock_up(ticker,dat)
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/hirelex/optionsalpha/optionsAlpha/trade_count.py", line
6, in stock_up
mu1 = MarketUpdate.objects.filter(Q(stock_symbol=ticker) &
Q(update_timestamp__gt=(test_start_date))).order_by('stock_value')
TypeError: an integer is required

I had tried it to solve it is working fine in django shell but
couldn't able to call it as a method Could you please point this?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Django urls in JavaScript

[Ayaz Ahmed Khan]

On Thu, Mar 17, 2011 at 7:44 PM, Marco Louro  wrote:
> I don't really know how to approach this issue the best way, so I'm
> just going to be direct, I'd love to see Django provide support for
> django.core.urlresolvers.reverse (at least) on the client (in
> JavaScript).
>
> [...]
>
> So my question is, is there any interest in getting something like
> this into Django itself?


Having run into this issue one too many times, I would like to raise
my voice to say that I am *very much* interested in having this
included in Django.

Ayaz

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Benevolent Dicta^H^H^H Designer for Life

[Raphael Passini Diniz]

Hi Idan,

Good luck! I'll expecting some exciting news! :D

2011/3/22 Wim Feijen 

> Hi Idan,
>
> Those are two great topics, congratulations to you and to us :) and
> good luck!
>
> Wim
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@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.
>
>


-- 
Atenciosamente Raphael Passini Diniz

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: secret key from file...

[Luke Plant]

On 22/03/11 12:44, Kristaps Kūlis  wrote:
>  I personally would greatly appreciate update in docs to show "best
> way" to handle per enviroment settings / sensitive settings, as now
> there is many ways :)
>  Consider when one has his local development enviroment with locmem
> cache and sqlite3 db, and staging server with MySQL / memcache and
> production cluster with MySQL (different credentials) and memcache
> cluster. In settings.py most deployment  specific stuff is left blank
> and on deployment {staging/production}_settings.py is created with
> from settings import * and then overriding per env settings :).
>  Actually it took me far too much googling to find "how" and "what" to
> do, at least I believe that such stuff should be put in docs to make
> django more sysadmin friendly.

One problem is that there are simply so many options, there is no 'best'
way. Every assumption made in this thread holds only for some
situations. And the solutions are not at all Django specific - every web
site, with any technology, has this issue i.e. where to put sensitive
configuration information.

Django's settings file gives you enough power to put this information
anywhere you like, and our documentation already points out that you can
use any Python to set the values of settings. We could make this a bit
more explicit to point that this means you can store settings not only
in other Python files, but anywhere.

Luke

-- 
"I am going to let you move around more, just to break up the
mahogany." (True Quotes From Induhviduals, Scott Adams)

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: secret key from file...

[Kristaps Kūlis]

 I personally would greatly appreciate update in docs to show "best
way" to handle per enviroment settings / sensitive settings, as now
there is many ways :)
 Consider when one has his local development enviroment with locmem
cache and sqlite3 db, and staging server with MySQL / memcache and
production cluster with MySQL (different credentials) and memcache
cluster. In settings.py most deployment  specific stuff is left blank
and on deployment {staging/production}_settings.py is created with
from settings import * and then overriding per env settings :).
 Actually it took me far too much googling to find "how" and "what" to
do, at least I believe that such stuff should be put in docs to make
django more sysadmin friendly.

Kristaps Kūlis



On Mon, Mar 21, 2011 at 8:01 PM, Matthew Roy  wrote:
> I don't think settings.py needs to be any more complicated by default.
> Personally, I do keep my db passwords in the settings file under version
> control. It seems pretty clear that it shouldn't be under public revision
> control. I also do (nearly) exactly what you describe to load the secret key
> from the filesystem.
> For the base installation the compromise of the settings.py actually isn't
> all that bad. MySQL defaults to listening only on localhost and the database
> user is mapped to localhost if you follow the tutorial. Memcache is a
> non-default addition, and IIRC also defaults to localhost. If I understand
> how it works the compromise of the SECRET_KEY alone doesn't put you in
> serious hot water unless the attacker can also intercept traffic. This leads
> me to the conclusion that a novice users really doesn't need to worry about
> heavily securing the values in settings.py until the are ready to grow their
> setup.
> That said, an automated tool to write a secret key to the file system and
> update settings.py to load it could make sense as a way to help users bridge
> the gap between the simple and moderately complex deployments.
>
> Matthew
>
>
> On Mon, Mar 21, 2011 at 13:07, Matt Harasymczuk  wrote:
>>
>> Thats right,
>> there should be a secret_settings.py file with db credentials and
>> secret_key
>> also a warning that it should not be added to version control
>>
>>
>> --
>> Matt Harasymczuk
>> http://www.matt.harasymczuk.pl
>>
>> On Mar 21, 5:07 pm, Kristaps Kūlis   wrote:
>> > "real" config should not be in version control system, only reference
>> > config should be stored in version control.
>> >
>> > Consider database credentials - they should not be publicly available
>> > / downloadable from internet and they fall in same category -
>> > sensitive information in settings.py .
>> > Memcache credentials - in many cases memcache is unprotected .
>> >
>> > I think docs should be updated to reflect sensitive settings.py
>> > variables, which are confidential and provide "best practices" way
>> > ({local|secret}_settings.py ?) for deployment :). Perhaps manage.py
>> > command to generate adequate strenght / randomness secret would be
>> > beneficial .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-developers@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.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@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.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: ANN: Django 1.3 release candidate available

[Russell Keith-Magee]

On Tue, Mar 22, 2011 at 6:23 PM, Wim Feijen  wrote:
> Great work!
>
> As the final release has not yet been announced, did something go
> wrong?
>
> Could you please post a small status update?

My apologies -- we haven't been very effective in communicating the delays here.

We've had a couple of holdups -- PyCon absorbed a lot of attention
from the community, and then delivered a whole lot of attention as
sprints took place. As a result, a bunch of release blocking bugs were
found, and had to be resolved.

The new djangoproject.com server has also caused some minor confusion
while we work out where everything is. This has required getting the
release team and the webserver team in the same place at the same
time, which is predictably difficult when we're talking about busy
people across all the world's timezones.

However, the wait should also be over -- we expect to release 1.3
final this evening, US time; less than 24 hours from now.

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-developers@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: ANN: Django 1.3 release candidate available

[Wim Feijen]

Great work!

As the final release has not yet been announced, did something go
wrong?

Could you please post a small status update?

Thanks,

Wim

On Mar 4, 7:00 am, James Bennett  wrote:
> Tonight we're proud to announce the first release candidate for Django
> 1.3; if all goes well, the final release will happen in about a week.
>
> Details for the release candidate are available on the official Django weblog:
>
> http://www.djangoproject.com/weblog/2011/mar/03/13-rc/
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of correct."

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Benevolent Dicta^H^H^H Designer for Life

[Wim Feijen]

Hi Idan,

Those are two great topics, congratulations to you and to us :) and
good luck!

Wim

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.