Re: ModelForms and the Rails input handling vulnerability

[Ian Lewis]

Hi,

I'm with Carl in supporting option 3. I think have always thought that
ModelForms were unsafe and requiring the fields option would go a long
way to making them safer. I don't think I'm stupid and I've personally
run into this issue. I have almost *NEVER* run into a case where I
want all fields on a Model to be updatable by the user and I now
always define the fields Meta attribute.

However, I'm not necessarily against leaving the current functionality
in Django for a few releases but with warning messages.

> So, to hit the problem the user would need to:
>  1. Have a ModelForm with no field restrictions in Python.
>  2. Render only part of the fields.
>  3. All non-rendered fields must be null/blank=True for the form to
> work at all.
>  4. Not use the form in update views.

No, the user would have to not miss of those things when developing.
Having a field get updated to NULL when not in the HTML does not
guarantee the developer will notice it. Maybe the field's default is
NULL? Or NULL is a perfectly valid value and they just don't notice? I
have been doing Django and Python for years at a high level and I have
done this.

On Tue, Jun 19, 2012 at 8:42 PM, Honza Král  wrote:
> I believe exclude is way more useful than fields (I do see the
> security advantage but in my mind this is the case where convenience
> beats security, also still afraid of the fields = [f.name for f in
> ...]).

Personally, I don't think convenience EVER beats security in a
framework like Django (if at all). This is the common "Oh but that
will never happen to me!" syndrome. Sane defaults that can be
overridden are going to always be better.

-- 
Ian

http://www.ianlewis.org/

-- 
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: auth.user refactor: the profile aproach

[Ian Lewis]

On Tue, Apr 10, 2012 at 11:58 PM, Tom Evans wrote:

> On Tue, Apr 10, 2012 at 3:13 PM, Ian Lewis  wrote:
> > Hi,
> >
> > I'm not getting why you *have* to add fields to the User model to store
> data
> > pertaining to the user. There is nothing in the proposal for pluggable
> user
> > models that says you can never have a seperate model with a foreign key
> to
> > the user model. It just means that you can define your user model the way
> > you want it to be.
>
> That is perfectly fine. The problem comes when there is a simple
> system to add fields to the user model, people will use it to add
> fields to the user model in their pluggable apps, for 'simplicity' and
> 'ease of use'.
>

Um. yeah. that's kind of the point. Third party apps being able to do so is
not good but me being able to do so is really really great. No proposal
that I've seen allows third party apps to add fields willy-nilly so what is
the problem here?


>
> > Why can't third party apps have a model with a foreign key to the user
> table
> > with the pluggable models approach? I imagine you are right that every
> app
> > and it's brother adding fields to the user model is not realistic but I
> > don't think that anyone has proposed that. Certainly not me.
>
> The proposed solution as decided by BDFL diktat is 2a from [1]. I quote:
>
> Split off as much as possible of auth.User into orthogonal mixins that
> can be reused.
> Modify auth.User to inherit these mixins. Care must be taken to ensure
> that the database expression of the new User model is identical to the
> old User model, to ensure backwards compatibility.
> Unrelated and third-party apps can indicate that they depend on
> various orthogonal mixins. For example, contrib.admin can specify that
> it works with auth.User out of the box, and with any model
> implementing PermissionsMixin if you supply your own login forms.
>
> At the moment, you cannot change the user model, so we do not have
> issues relating to third party apps changing the user model. With the
> proposed solution, you would be able to change the user model, so we
> may have issues.
>

Yes. Third party apps changing the user model is bad. I agree. You should
need to explicitly add
any field the third party app needs. Preferably these would be common
things like 'email' or the user's name.
Any other app specific data would go in models provided by the app with an
FK to user.

In other words, an app providing a user model mixin that YOU add to your
user model is OK, though probably bad design.
For third party app related data, it makes sense to have it in a separate
table. I imagined that that mixins would be there
so that you could choose to add or not add the fields to support the admin,
but apps providing mixins to add fields
to the user as a normal design is probably a bad idea. I see where I may
have been confused.

It's also enlightening to read the code from Alex's Django branch,
> which is an initial implementation of option 2a.
>

I haven't seen that so I can't comment.


> > The thing I
> > want to be able to is define user models suitable for my project. Third
> > party apps adding their own fields wasn't proposed by anyone AFAIK, nor
> was
> > specifically requiring that you add them yourself. Some might require
> that
> > your user has something like an 'email' field because that would be a
> common
> > field across apps but app specific data can easily go on a seperate model
> > included with the app that simply has a FK to user. You can then only
> fetch
> > that data on requests that need it.
> >
> > I'm sorry but doing a JOIN every request is a BAD idea. You will run into
> > problems there quickly and have no way out of it besides ditching auth
> > completely (and thus all the thirdparty apps you use that depend on it).
>
> I completely disagree, but I'm not here to try and convince people how
> to design their databases. A JOIN every request will not end the
> world. Besides, it is far more likely to be a separate query than a
> JOIN, and would only happen on views that required that data.
>
> More to the point, what basis are you making this claim on? People
> love to pipe up "JOINs are slow and evil", but have you actually
> analysed the cost compared to monolithic tables?
>

I'm assuming that you will not have a monolithic table with 100s of columns
because that would be silly but I can
see now that developers of third party apps might think that's the way to
add user specific data. Like I said,
I think that having fields added to the user model by third party apps etc.
is dumb but I neve

Re: auth.user refactor: the profile aproach

[Ian Lewis]

Hi,

I'm not getting why you *have* to add fields to the User model to store
data pertaining to the user. There is nothing in the proposal for pluggable
user models that says you can never have a seperate model with a foreign
key to the user model. It just means that you can define your user model
the way you want it to be.

Why can't third party apps have a model with a foreign key to the user
table with the pluggable models approach? I imagine you are right that
every app and it's brother adding fields to the user model is not realistic
but I don't think that anyone has proposed that. Certainly not me. The
thing I want to be able to is define user models suitable for my project.
Third party apps adding their own fields wasn't proposed by anyone AFAIK,
nor was specifically requiring that you add them yourself. Some might
require that your user has something like an 'email' field because that
would be a common field across apps but app specific data can easily go on
a seperate model included with the app that simply has a FK to user. You
can then only fetch that data on requests that need it.

I'm sorry but doing a JOIN every request is a BAD idea. You will run into
problems there quickly and have no way out of it besides ditching auth
completely (and thus all the thirdparty apps you use that depend on it).
Assuming the user table and profile tables are small is awfully short
sighted.

Ian
2012/04/10 18:47 "Tom Evans" :

-- 
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: auth.user refactor: the profile aproach

[Ian Lewis]

Hi

iPhoneから送信

On 2012/04/06, at 0:29, "Daniel Sokolowski"  
wrote:
> The more I think about it the more it makes sense to me to have a base User 
> model just a stub with a user Identifier and password field. Sure one could 
> argue for less ore more fields, but I think the idea
> is to pick something that would work in 95% situations and yet be flexible 
> enough to be extended as you wish. Need to extend to add your own 
> authorization you create a profile with a FK key to the base model and
> a new auth backend.

The good part about swappable user models is that you don't need to necessarily 
fix the model's DB fields in advance. Your identifier and password's length and 
other properties can be user defined and can be reflected in the DB.

Django can also leave migration of user models an data up to the developer so 
they an use south or whatever to manage the user model since they "own" it. 
Django Devs wouldn't necessarily need to support a DB table that can 
essentially never change as is the case currently.

Fixing that stuff ahead of time and just making a FK means the user model 
itself is fixed. I don't want to be able to just add fields. I want to be able 
to change the primary key to be a uuid, or a email, or use the default auto 
incrementing integer. I want to be able to use an existing model or DB table 
and, with some work, plug it into Django auth.

Now if I'm customizing the user model itself anyway, why not just tack on 
whatever other fields I want? I don't need a FK since those fields are on the 
user model and I can create however many one to one or one to many 
relationships for "profiles" or user data as makes sense for my project. That 
may be a lot or it may be zero. 

(now whether that is realistic given the needs of the admin is a different 
story)


> Perhaps the reason the current contib.auth is still not overhauled is because 
> it does work for a large number of situation and extending it is relatively 
> easy. Keep the solution simple - I think we are overthinking it.

Sure. I'm not completely discontent continuing to use my own library and simply 
shun anything that uses auth (besides the admin maybe), but I think Django 
would be better off with a better auth module. 


> -Original Message- From: Russell Keith-Magee
> Sent: Wednesday, April 04, 2012 10:44 AM
> To: django-developers@googlegroups.com
> Subject: Re: auth.user refactor: the profile aproach
> 
> 
> On 04/04/2012, at 8:44 PM, Tai Lee wrote:
> 
>> I'm not so sure that it's necessary or even desirable to solve the "general" 
>> problem of swappable models. If anyone can swap any model by changing a 
>> setting, that sounds like a recipe for confusion to me.
> 
> Sure, but that's not what I've proposed. A model would only be swappable if 
> the original app developer declared that model as swappable. An end user 
> wouldn't be able to arbitrarily decide that they wanted to replace a model in 
> an app developed by someone else.
> 
> And sure, any feature we add could ultimately end up being used (and 
> overused) in bad ways. However, that's true of any language or library 
> feature. Classes, metaclasses, decorators, or any other Python language 
> feature can be both used and abused, as can Django features like ModelForms 
> or the internals of the Meta class.
> 
> My point is that there is nothing about this problem that is unique to User. 
> Django's own codebase contains another example of exactly the same pattern -- 
> Comments. Therefore, we shouldn't pretend that the solution is User specific. 
> At some point, we have to just provide enough documentation and guidance to 
> shepherd people away from bad architectural decisions, and trust that the 
> userbase will take that advice.
> 
> 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.
> 
> -- 
> 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: auth.user refactor: the profile aproach

[Ian Lewis]

Hi. 

iPhoneから送信

On 2012/04/04, at 5:34, Adrian Holovaty  wrote:
> First, some background: I haven't used the built-in User module in
> several years. I always write my own User model from scratch -- it's
> so nice and clean. Want a twitter_username field? Just add it. No need
> to add a convoluted foreign key or (oh god) one-to-one relationship to
> some other table.
> 
> To me, this is the Right Way to do things. The framework should bend
> to my needs, I shouldn't bend to the framework's needs.
> 
> Also, profile modules need to die. They needed to die circa 2006.

Yes, Yes, Yes. I'm really glad someone besides me disliked user profiles and 
favored just creating your own user model. I was feeling lonely.

Just like Adrian, me and everyone at my company have used our own user models 
for years. It always felt like the simplest and most straight-forward approach. 
It also has the be benefit that users can use south or anything they want. For 
migrating and managing user data. Big big +1.

> So, with that in mind, I've got to say I prefer Alex's solution. I
> really think the right way to do it is:
> 
> 1. Let you create your own User model, with whichever fields you want.
> 
> 2. Provide a way to tell Django which model you're using for that.
> 
> 3. In your own code, just deal with that model like you deal with any
> other one. No need to jump through hoops.
> 
> 4. Third-party models should be changed to use something like "user =
> UserField()", which would automatically create a foreign key to the
> registered User model. If you change your registered User model after
> you've created those third-party tables, you're in for trouble. Don't
> do that.
> 
> 5. Django provides some generic APIs for getting at the registered
> user. Example: a middleware that sets request.user based on the
> current session.

I wanted to point out that Adrien's plan is pretty close to newauth. Though I 
didn't go so far as to provide a UserField, I did have a way for third party 
apps to get a handle of the User model via a get_user_model() function. The 
UserField would just glue something like that to a ForeignKey.

> 6. Given that some third-party apps will likely want to get access to
> common attributes of a User -- notably, email address -- there could
> be some sort of standard interface that User models need to adhere to
> (duck typing). So, a custom User model would say "for this User model,
> the email address is stored in the database field called 'email'" --
> or "this User model doesn't have email addresses.

I think people get too hung up on providing fields do third party apps when you 
could provide a minimal set of methods which subclasses could override. There 
isn't really any reason i can think of that third party apps need to access the 
fields directly.

Though if you really hav to deal with fields, I prefer a simple convention for 
common fields; for example, 'email' for the email field. That way you can do a 
simple hasattr() to look if the model has a particular field. I realize 
convention is hard to document though.

I'm curious though how the admin fits into your ideas. If you wanted to use the 
admin, would you have to use a User model that has and or supports all the 
cruft on the current user model? e.g. username, password, email, permissions 
etc.

All in all I'm excited about where this is going and that you're taking the 
lead on this. Can't thank you enough. 

-- 
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: auth.User refactor: reboot

[Ian Lewis]

Hi

On Fri, Mar 23, 2012 at 8:41 PM, Hanne Moa  wrote:

> On 21 March 2012 09:40, Ian Lewis  wrote:
> > To my mind it's the least important of the tenets of the design of
> > newauth, but I personally would like to use it at least for admin
> > users and normal site users. The issue for me is that the
> > functionality required of users of the admin will be different from
> > users of the site itself.
>
> You don't need several user models if you have several user profiles
> *per user*. With a minimal User-model (the absolute minimum is one
> having only a primary key) with several user profiles (onetoone keys
> to the primary key on the minimal User-model) you can still get
> completely rid of users in all of their roles by nuking the entry in
> the User-table and have it cascade down.


I think this is basically a difference in way of thinking where you are
thinking that the admin and site are the same *site* and the user just has
an admin *role* and a site user *role*, whereas I see them as separate
*sites*.
Users in one have very little to do with users in the other. The different
roles
require different data. If I make a django user without the needed data on
the site
it could break my site. I suppose that you can have django admin users
without
a site user by not creating a site profile, but then I need to check that
the site profile
exists for all site requests and third party apps need to be implemented
properly to
check for proper profiles etc. This isn't how django has typically worked.
Whether
you were an admin user or normal user has nothing to do with profiles and
had
to do with the is_staff flag.

Basically up until now, if you have a django auth user
you have a site user. All third party apps work this way. Few actually look
at the
object returned by get_profile() because they wouldn't know what they'd be
looking
at if they did. The problem is that means that the way most apps work and
how most
people write django apps, I *have* to have a site user to have an admin
user. All
admin users have to register with my site and have a public profile and
everything in
order to use the admin because creating an admin user means creating a User
object.

I've personally solved this problem by not using these kind of apps but
would like
a solution that isn't so inflexible. I think my proposal could be expanded
a bit to
allow both ways of doing things and still be backwards compatible the
default
being the way that django currently works.

If the admin-role of a user
> is disconnected from the normal user role,  you'd need to manually
> delete twice in two different models. Read: error-prone!
>

I think we may be talking past each other a bit here.
In my mind, admin users are *separate* from site users. I don't really
*want* to delete both the same time.
If an employee that uses the admin deletes his example.com site user
through the site,
then not being able to log into the admin is a big problem. Conversely If I
create a user
in the django admin the user doesn't necessarily go through the same
process as registering
on the site does so they don't have the required data for the site itself
to work. I don't want to have
to create site users, or make people register with the site just so they
can use the admin.

Personal experience probably shouldn't really dictate how auth is designed
but the admin for
every site I've ever done is not even reachable by normal users and is at
a different domain
and admin users don't do admin work on the site itself but through the
admin. So single sign
on with site itself is not helpful and actually scares the bejebus out of a
lot of our clients.
There's no reason to have the site user be tied to the admin user, and
create and delete
and manage them all at once. At least for me.

I can imagine cases for content heavy sites where staff comment and
moderate and bounce
around between the admin and site but there's nothing stopping you from
signing in in
both places even if my proposal made you do that, which it doesn't.



The triangle has *three* corners. Identity, Authentication,
> Authorization. If any two corners are combined, yes, even if Identity
> and Authentication is combined,  there *will* sooner or later be
> trouble. "username" part of the Authentication-process need not be
> combined with what the user sees (if anything) in a "Hello, ,
> you are now logged in".message. That's what a displayname is for.
> Django.admin would need to ship with an AdminProfile-model. The
> auth-backends could authenticate towards a specific AuthProfile then,
> splitting identity from authentication.
>

Ok. so you are saying the profile is what you auth against? That's a really
silly name then.
If that's the case and the profile contains credentials for auth then maybe
I&

Re: auth.User refactor: reboot

[Ian Lewis]

Hi,

On Tue, Mar 20, 2012 at 10:37 PM, Russell Keith-Magee
 wrote:
> On 20/03/2012, at 8:38 PM, Tom Evans wrote:
>> User profiles solve the issue of app specific data in a better way
>> than specifying additional fields on a a base user object,
>> particularly as the number of apps increases. Whilst there is an
>> additional cost in joining to the user profile table, typically in
>> app1 you only need app1.UserProfile, and not appN.UserProfile.
>
> Go back and read my posts -- I've repeatedly said that I prefer UserProfile 
> as a pattern for *app specific* data. The only role that I see pluggable user 
> models solving is the issue of username and email length/uniqueness, and/or 
> the tracking of additional data required for the authentication process. 
> Anything else app specific should be kept in a UserProfile (or UserProfiles, 
> or some other model related 1-1 with User).
>
> A side effect of pluggable user models is that it would allow people to put 
> their profile data on their User model. However, as you point out, that has 
> all sorts of complications, and requires the User object to become a 
> monolith. I wouldn't recommend this approach, but as this thread has 
> revealed, many people prefer this approach for performance or aesthetic 
> reasons. The upside is that pluggable user models allows for this approach if 
> people want it. However, that doesn't mean that the Django docs should 
> encourage it.

I just wanted to state, perhaps obviously, that UserProfiles are
really just models that have a fk to the user table. Nothing in my
proposal says you can't do that, or even recommends against it. I
think app-specific data should go in these kind of models. The user
models in my proposal would be models where you define on the model
what is needed for authentication, what the pk is, and perhaps some
other common profile data that is commonly used (like the user's name
and email or something). I'm not saying you should put everything that
ever had anything to do with your user on the user model.

>> I would disagree with this. The immediate problem from my POV is that
>> a user who takes the latest release of django, installs the stock auth
>> app has an email field which cannot hold valid email addresses, and a
>> username field that cannot hold email addresses. It's unclear that
>> your proposal changes this at all.
>>
>> One issue that you have not mentioned at all is schema changes with
>> pluggable user models. If your average user is going to specify what
>> fields his User model has in it, what processes will be put in place
>> to allow the user to move from their current auth_user table
>> structure?
>>
>> What about fixing the stock model definition (which will still have an
>> email field, I assume)? Since schema changes have not been mentioned,
>> I'm inferring that this would not change, and the 'fixed' version of
>> django, by default, would still disallow a wide range of valid email
>> addresses.
>
> My proposal for this would be to treat the migration process the same as 
> we've done for any other feature that we've added to Django -- make it an 
> opt-in change with a documented migration path.
>
> For example, when we introduced localization, we set the default to USE_L10N 
> = False, and made the default behaviors unchanged from the older unlocalized 
> behavior. However, if you opted in to USE_L10N = True, you got all the nice 
> new localization features, and possibly a couple of migration headaches. 
> However, because it was an explicit opt-in, you're on the lookout for things 
> that might have changed or broken.
>
> Similarly, I would argue that we if we include this change, we have to ship a 
> concrete User model that is *unchanged* from it's current definition. We then 
> have three options:
>
>  1) Ship an updated User model (say, SimpleUser) with corrected email 
> max_length (and any other changes that pop up). We document the process for 
> opting in to using SimpleUser, including the ALTER TABLE statements that are 
> required to modify any existing databases.
>
>  2) Ship a range of sample User models representing common User model 
> patterns (e.g., using email as login, username but no email, etc) and provide 
> the migration path for each.
>
>  3) Punt on the entire issue, document the limitations with the built in User 
> model, and let the community manage User models; document what people need to 
> do in order to switch, but leave migration as an open question that people 
> providing new User models need to answer.
>
> Personally, I'd be in favor of option (3), mostly because what the last 6 
> years has taught us is that no matter what we pick as field names/sizes, 
> *someone* will be unhappy. However, I won't get too bent out of shape if 
> Django ends up shipping at least 1 new concrete User model -- at the very 
> least, it's a good way to prove we can eat our own dogfood.
>
> If we introduce 1-N new User classes, we could also take the opportunit

Re: auth.User refactor: reboot

[Ian Lewis]

Hi,

On Tue, Mar 20, 2012 at 2:05 PM, Russell Keith-Magee
 wrote:
> On 20/03/2012, at 8:00 AM, Ian Lewis wrote:
>> Though we have had other times where there were multiple types of
>> users in a single project. i.e. users that signed up via some
>> affiliate program. username is unique so you wouldn't be able to use
>> the same username across user account types etc.
>
> I can see the use case here, but it seems to me that this is exactly what 
> UserProfiles (or a denormalized User model with multiple auth options) should 
> be used for.

With user profiles you have one single user and username/email
namespace whereas what I'm talking about are user namespaces and types
that are completely separate from each other. Sure you *could* make
everyone register once and then tack on user profiles based on what
things the user is signed up for or whatever but it seems like
something that the framework doesn't need to mandate. No argument
against it being the recommended way to do multiple users though.

> There's a very practical reason I say this -- If you have two separate user 
> models, aren't ForeignKeys a complete PITA?
>
> Lets say you have two different user types -- say, FacebookUser and 
> TwitterUser. Now, I create a comment model, and a comment has an Author which 
> is a User. How do I set up this foreign key?
>
> If FacebookUser and TwitterUser were set up as different subclasses/profiles 
> of User, then there's a common base class you can reference in a FK; but if 
> they're completely separate keys, you've either got to use 
> GenericForeignKeys, have two foreign keys every time you want to reference a 
> user, or maintain a third table that unifies the two user types.
>
> I feel like I must have missed something obvious here (either in your use 
> case or in your technical solution), because this seems like a pretty big 
> hurdle.

Hmm, I'm imagining different types of users with orthogonal spaces
rather than a two user types that can essentially do the same thing. I
suppose the use case I'm trying to describe isn't encountered very
often which is why it's hard to explain or visualize. If you had the
kind of user you are describing there is no doubt you would have a
user table and have profiles or a related model. This is part of the
reason it's at the bottom of the list of features I described earlier
(it was sorted by importance).

>> Granted separation
>> *may* be done by creating a whole separate project and isolating
>> common code into a library but auth/admin is currently making it so
>> you *have* to do it that way.
>
> One option is to allow auth to support multiple models, as you've done.
>
> A second would be to have a separate project, as you alluded to earlier.
>
> The third option would be to have multiple auth apps -- e.g., one for admin 
> users, and one for regular users. Yes, there's a configuration issue of 
> determining which auth app you want to use in different circumstances, but 
> that's going to exist anyway under your approach -- you're going to need apps 
> to know how to ask for the "right" User model.
>
> The problem I'm having with your newauth is that I'm not yet convinced that 
> the use case you present is enough to warrant adding a 'multiple user model' 
> capability to Django's base auth app -- especially if you can achieve the 
> same end by having multiple auth apps, or parallel projects.

To my mind it's the least important of the tenets of the design of
newauth, but I personally would like to use it at least for admin
users and normal site users. The issue for me is that the
functionality required of users of the admin will be different from
users of the site itself. Part of the problem with the current auth is
that it's forcing a number of fields and functionality on developers
that isn't necessary for their site for the sake of the admin. This is
probably my strongest argument and feeling for having multiple user
models, at least as far as the admin is concerned. I just don't really
see any reason why users on the site needed to share any data with
admin users so I separated them and (would) made them different models
(currently they are separated simply by the fact they are in different
apps).

>> I just think that the current auth app is mandating a certain way of
>> doing things that it doesn't necessarily need to and most users just
>> deal with it, in some cases bending over backwards, because they want
>> to use auth's API. That's the way I've always felt.
>
> I'm in complete agreement that the bits like username and email 
> size/uniqueness are completely arbitrary, and should be user-configurable

Re: auth.User refactor: reboot

[Ian Lewis]

Hi,

On Mon, Mar 19, 2012 at 9:27 PM, Russell Keith-Magee
 wrote:
> On 18/03/2012, at 12:19 PM, Ian Lewis wrote:
>> I meant one that was a completely separate concrete base model. The
>> current auth forces you to take along with you all the fields on the
>> User model.
>
> In the current setup, then yes, you need to bring along all the fields of the 
> current User mode. But if we're refactoring so that you can have a pluggable 
> User model, then "all the fields" can be a minimal subset if you want it to.

Yeah, I think we want the same thing here though, ideally, I don't
think there really is a minimal subset, but rather just the "contract"
you spoke of earlier.

> I've had a chance to take a closer look at your code, so I've got a clearer 
> idea of how your setup works now.
>
> If you'll permit me the liberty of reducing all your hard work into a set of 
> bullet points, here's what I see:
>
>  * Middleware, views and backends that mostly mirror Django's existing auth 
> implementations
>
>  * An abstract base class with a minimum feature set.
>
> No argument that this is the right approach.

I tried to include the things that made sense in the original auth app.

>  * No permissions or groups.
>
> I appreciate that this is probably because you haven't got a need for them; 
> but from Django's perspective, we need to have those pieces defined, because 
> it's required for admin. However, in whatever we do, we should follow your 
> example and maintain a clear separation between the two concerns (e.g., 
> define the fields required for authentication separately from the fields 
> required for authorization).

The permissions weren't implemented because I had no need for them. I
thought that ideally it would be a separate app or something but for
backwards compatibility you would at least need to be able to access
permissions via the auth app :-/

>  * A mechanism for plugging in (and finding) a concrete user class.
>
> Although the names are a bit different, the general plugable solution you've 
> isn't that far removed from what has been proposed in the past with a 
> AUTH_USER_MODEL setting (or similar). This is essentially what #3011 
> originally proposed, what Clay McClure has proposed in the branch he posted, 
> and what contrib.comments does.
>
> The biggest argument against this approach is that it introduces a circular 
> dependency between models.py and settings. When Django starts up, one of the 
> first things it does is load the settings module; this populates 
> INSTALLED_APPS, which in turn imports each the models.py for each app. If 
> models.py imports settings, you can get into some interesting territory.
>
> Unfortunately, it's also one of those things that tends to work *most* of the 
> time; it's only the edge cases where you get bitten.
>
> The upside to using the AppRefactor+LazyFK approach that I've described is 
> that it breaks this dependency. The App object defines all the configuration 
> parameters, and is loaded when INSTALLED_APPS is configured; models.py can be 
> imported without reference to the App; and the final model step of 
> configuring model references can be performed with an app cache that is known 
> to be fully populated.
>
> It also has the benefit that it provides a general solution to the common 
> problem, so that other app writers don't have to reinvent the same "find 
> app/find model" wheel when faced with a similar plugable problem.

I agree that the LazyFK is a better idea. I did it this way to make it
easy to use, i.e. without much explanation, in third party apps and
because I wasn't prepared to include something like the LazyFK.

>  * One very big new feature -- the ability to have multiple User models in 
> the same project.
>
> This is the one controversial part of your proposal, from my perspective. In 
> every situation I can think of, I can only see it being an annoying -- e.g., 
> having an admin username that is different from my normal user username; 
> duplicating foreign keys to two different types of User object, and so on. If 
> it wasn't for this last point, I'm reasonably certain that your newauth could 
> be achieved through a series of progressive enhancements to the existing auth 
> app.
>
> I'm sure you haven't done this just for giggles -- so what is the use case 
> for this feature?

Personally, it would mostly be used to separate users of Django's
admin and normal site users. Most of our clients get really nervous
when we say "You just log in with the same username and password as
you use on the regular site!". Also the admin users might come with a
lot of baggag

Re: auth.User refactor: reboot

[Ian Lewis]

Hi,

On Mon, Mar 19, 2012 at 1:00 AM, Joe Tennies  wrote:
> A feature I would love to see is the ability to support multiple forms of
> authentication for a single user account. (One account to many credentials.)

You can do this already with Django auth by specifying multiple
backends to the AUTHENTICATION_BACKENDS setting. Each one can take
different credentials but potentially return the same User.

See: 
https://docs.djangoproject.com/en/1.3/ref/settings/#std:setting-AUTHENTICATION_BACKENDS



-- 
Ian

http://www.ianlewis.org/

-- 
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: auth.User refactor: reboot

[Ian Lewis]

Hi,

On Sun, Mar 18, 2012 at 9:41 AM, Russell Keith-Magee
 wrote:
>> 1. Django shouldn't decide what fields go on the user model. The app
>> provides an abstract base class which developers subclass to add the
>> appropriate fields they need.
>
> +1

THX

>> 2. Django shouldn't decide the type of the primary key. The app only
>> relies on the fact that the object has a pk. The id field can be named
>> anything you wish and can be any type (integer, char, uuid, etc.).
>
> +1

THX again

>> 3. Third party apps don't rely on the user having any fields but
>> rather the base user class defines methods that are implemented by
>> subclasses. Methods like get_display_name() which provides a way for
>> third party apps to get something to display.
>> 4. Rather than provide mixins or something, we should have conventions
>> for the field names like 'email' and third party apps should check if
>> the user has one using duck typing e.g. hasattr(user, 'email').  An
>> alternative could be to provide some kind of API for commonly used
>> actions like emailing users.
>
> This is essentially all I was proposing when I spoke of an "admin User 
> contract"; that we define some basic "identity" functions that every User 
> object is expected to provide -- short name, long name, and so on.
>
> The admin case is a little more complicated because there is also a required 
> API for permissions and groups, but to my mind, these are different 
> contracts, and should be documented as such.

My solution is simply authentication, authorization would need to be
added on or in a separate app built on top of newauth.

>> 5. Basic username (or email)/password authentication can be provided.
>> The app has a base user class from which a basic abstract user with
>> username/password is defined. This can implement setting passwords
>> properly and provide forms etc.
>> 6. Multiple user models can be defined (Like say for normal users and
>> affiliate users or admin users). If one wants to create a project
>> currently with a separate user model, none of the machinery in the
>> auth app can be used.
>
> Sure you can -- you have a base User, and then subclasses to get AdminUser 
> and NormalUser -- both of which are effectively just another type of 
> UserProfile.

I meant one that was a completely separate concrete base model. The
current auth forces you to take along with you all the fields on the
User model.

>> You create users by creating your own app in your project and creating
>> a User there:
>>
>> account/models.py
>>
>> from django.db import models
>>
>> from newauth.models import UserBase
>>
>> class User(BaseUser):
>>    full_name = models.CharField(u"Full Name", max_length=255)
>>    email = models.EmailField('Email Address')
>>    profile = models.TextField('Profile Bio', blank=True, null=True)
>>    avatar = models.ImageField('Avatar', upload_to='profileimg/',
>> blank=True, null=True)
>>
>>    def get_display_name(self):
>>        return self.full_name
>>
>>    class Meta:
>>        db_table = 'my_user_table'
>>        verbose_name = u"Djangonaut"
>>        verbose_name_plural = u"Djangonaut"
>>
>> There are even docs and tests.
>
> How does this address the issue of reusable apps referencing User? Let's say 
> I write a comments app, and want an Author field. I need a ForeignKey to 
> "User". But I can't have a foreign key to BaseUser, because it's an abstract 
> class. How do I define my Comment model in such a way that it can reference a 
> generic "User"?
>
> It seems to me that the solution you're proposing requires the LazyFK and 
> app-refactor infrastructure I've described in order to be useful in the 
> general case (not that I'm complaining, mind -- just pointing out that our 
> two proposals are complementary :-).

This is a bad example for showing how that works. I just wanted to
illustrate how you would make your own User model. In the case where
you want a foreign key to User you can import the default user model
from newauth.models as User much like you do with the current django
auth app.

See: http://ianlewis.bitbucket.org/django-newauth/third_party.html

>> This is going to be the biggest problem with my solution. There would
>> probably have to be some kind of compatibility layer added to make
>> existing apps work or to provide a simpler migration path.
>
> Isn't the compatibility layer just an implementation of the existing 
> auth.User class that extends from BaseUser? We're going to have to ship this 
> user class anyway, so that everything works out of the box; then if anyone 
> wants to define their own User class, they can.

Perhaps. I think in reality it will be a bit more complicated though I
haven't really thought about it. I didn't really consider
authorization or backwards compatibility as a goal of the project when
first writing it.

>>>  * It solves the immediate problem ...
>>>
>>> As I see it, the immediate problem is that developers want to be able to 
>>> modify the base requirements of

Re: auth.User refactor: reboot

[Ian Lewis]

Hi,

Eric Florenzano and I actually had a discussion about this at PyCon.
My company does Django development and simply doesn't use the Django
auth app because it tries to do authentication and authorization in
one app and the User models are just to inflexible. Many projects
didn't need or want usernames, email etc. and many required changing
the fields on the model. Using the get_profile() method in every view
and in every template was also a huge pain in the ass.

I have a concrete proposal and implementation that I wrote for our use
that solves a lot of the issues that have come up here. I have been
brushing up the api and documentation recently to release it but I'd
like to speed things up and release it publicly. The app is built on
some basic tenets in order of importance:

1. Django shouldn't decide what fields go on the user model. The app
provides an abstract base class which developers subclass to add the
appropriate fields they need.
2. Django shouldn't decide the type of the primary key. The app only
relies on the fact that the object has a pk. The id field can be named
anything you wish and can be any type (integer, char, uuid, etc.).
3. Third party apps don't rely on the user having any fields but
rather the base user class defines methods that are implemented by
subclasses. Methods like get_display_name() which provides a way for
third party apps to get something to display.
4. Rather than provide mixins or something, we should have conventions
for the field names like 'email' and third party apps should check if
the user has one using duck typing e.g. hasattr(user, 'email').  An
alternative could be to provide some kind of API for commonly used
actions like emailing users.
5. Basic username (or email)/password authentication can be provided.
The app has a base user class from which a basic abstract user with
username/password is defined. This can implement setting passwords
properly and provide forms etc.
6. Multiple user models can be defined (Like say for normal users and
affiliate users or admin users). If one wants to create a project
currently with a separate user model, none of the machinery in the
auth app can be used. With the above approach multiple user models can
be defined and used without any problems. It doesn't make much sense
to only allow one user model and only that model can use the auth API
and machinery. A default user model can be defined and imported via
the models module. Admin users can also be defined completely
separately from normal users.

You create users by creating your own app in your project and creating
a User there:

account/models.py

from django.db import models

from newauth.models import UserBase

class User(BaseUser):
full_name = models.CharField(u"Full Name", max_length=255)
email = models.EmailField('Email Address')
profile = models.TextField('Profile Bio', blank=True, null=True)
avatar = models.ImageField('Avatar', upload_to='profileimg/',
blank=True, null=True)

def get_display_name(self):
return self.full_name

class Meta:
db_table = 'my_user_table'
verbose_name = u"Djangonaut"
verbose_name_plural = u"Djangonaut"

There are even docs and tests.

Check the source out here: https://bitbucket.org/IanLewis/django-newauth/
See the docs here: http://ianlewis.bitbucket.org/django-newauth/

Having used this at my company for over a year, I can say it's
extremely nice and has worked well for us. I hope that the
implementation and docs can serve as a reference for any improvements
to Django auth.

Some other miscellaneous thoughts below:

On 17/03/2012, at 12:53 AM, Jacob Kaplan-Moss wrote:
> 2. Complete improvement: recognize that the auth app is fundamentally flawed, 
> and mercilessly refactor/replace/rewrite it, all in one go. The hypothetical 
> results here would be better -- a modern auth system unencumbered by the 
> decisions we made in 2005 -- but this would take far longer, and would block 
> on things like the app refactor and schema migrations.

I'm in favor of this kind of solution personally but I think it will
really throw other projects for a loop. Especially projects like Pinax
which rely heavily on the auth.User models.

>> There's also a middle-ground proposal from Clay: make the auth app 
>> swappable, thus making it possible for *users* to replace the auth app while 
>> leaving time for us to make either incremental or complete change, as we see 
>> fit.

I'm not really in favor of this for the reasons Jacob mentioned.

On Sat, Mar 17, 2012 at 2:59 PM, Russell Keith-Magee
 wrote:
>  * Add the concept of a LazyForeignKey.
>
> LazyForeignKey is a normal foreign key, with all the usual foreign key 
> behaviors; the only difference is that the model it links to isn't specified 
> in the model -- it's a configuration item drawn from an application 
> configuration. So, ForeignKey('auth.User') creates a foreign key to 
> django.contrib.auth.User; LazyForeignKey('auth.User') asks the 

Re: contrib.staticfiles app concerns

[Ian Lewis]

On Thu, Oct 21, 2010 at 12:25 PM, Jannis Leidel  wrote:

> Ian,
>
> > I thought about this too and had a long thread on Twitter with jezdez
> about staticfiles. It occurred to me that adding more apps to contrib was
> kind of a bad idea. I know "everyone" uses admin etc. but I was of the
> understanding that contrib apps are optional apps for django but staticfiles
> doesn't seem to be that way.
>
> Repeating what I said briefly on Twitter, the reason to extend this ability
> was to give a better answer to "How does Django help me to manage and deploy
> static files?" In that sense, the contrib staticfiles app is really just an
> extension of the tools that Django already provides, the media context
> processor, the static view and the WSGI Middleware for runserver -- plus a
> few optional helpers like a template tag, management commands and extensible
> file finders that work similar to template loaders. All of which are not
> required to run a Django site.
>
> > The core 'django.views.static.serve' and
> 'django.core.context_processors.media' are deprecated in favor of the
> staticfiles equivalents in contrib. Is the idea that the contrib app is a
> stepping stone to providing core functionality? i.e. It was put in contrib
> to maintain backwards compatibility for at least enough time to satisfy the
> deprecation policy? I'm also getting worried in general about adding more
> and more functionality to Django that doesn't really *need* to be there.
>
> Moving pieces of code arund is part of the development process and hasn't
> really been done just for the sake of it. Personally, I don't share your
> worry about added functionality, as long as it solves real world problems,
> which staticfiles certainly did for me, as well as for the hundreds of other
> users, too.
>

I certainly agree it's useful. I use it for my projects. I just don't think
it needs to be in core. Anyone that needed this functionality could simply
install and use django-staticfiles. For me, adding everything and the
kitchen sink to Django with no clear scope is worrysome. Anyway, this part
of the conversation at least isn't productive so it's the last you'll hear
from me on it.


> > On a seperate topic, it occurred to me that if you wanted to use the same
> backend for your STATIC_STORAGE as you use for DEFAULT_STORAGE then you'll
> run into problems if you want to use different options for each. The docs
> mention django_storages but you'll be hard pressed if you want to store your
> static and user media in different buckets. It's one of the reasons I added
> options to the constructor for the s3boto backend (I'm the current
> maintainer) in django_storages and added a STATIC_STORAGE_KWARGS in my
> branch of staticfiles on bitbucket.  Not sure it was the best solution, but
> it works.
>
> I would like to stress that using the same storage backend for static files
> and user generated files is considered bad practice, which is also why I
> haven't applied your changes in the staticfiles app. It was a distinct
> design decission to have both kinds of files in different locations and to
> provide the STATICFILES_STORAGE next to the DEFAUL_STORAGE setting for
> further extension.


I can imagine situations where you would want to store uploaded data and
static files in S3 (but in different buckets or directories) to take
advantage of the Cloudfront CDN. That just one example but I'm sure there
are others such as storing static media in a normal directory and uploaded
media on a shared NFS mount (some people do that). I suppose subclassing the
backend simply to provide different options would be doable but didn't seem
as nice at I need to support it in code rather than just changing some
settings. That said, the StaticFilesStorage seems to do exactly what you
described so if it's discouraged for some reason (which I'm still not sure I
understand) then I'll respect your API.


> I can't comment on the backends in django-storages much since I'm not very
> familiar with the code, but I assume that it's possible to subclass those
> storage backends to change the options, as needed. An extended example on
> djangosnippets.org or in the django-storages docs would cetainly be useful
> to have of course. If you have any suggestions regarding the staticfiles
> docs with regard to using other storage backends, I'd appreciate your help.
>

For the S3BotoBackend at least, you would just need to subclass and override
the __init__() method to call super() with the options you need, which would
mostly likely be environment specific and set in the settings.py anyway.

-- 
Ian

http://www.ianlewis.org/

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

Re: contrib.staticfiles app concerns

[Ian Lewis]

On Thu, Oct 21, 2010 at 2:40 AM, Waldemar Kornewald wrote:

> Today the staticfiles contrib app was committed to trunk. This got me
> wondering: Wasn't there recently a discussion about how "contrib" is a
> bad idea and all apps should either be in core or live as separate
> projects? Is staticfiles really a core app? Even if it is a core app,
> does it do its job well enough to be in contrib?
>

I thought about this too and had a long thread on Twitter with jezdez about
staticfiles. It occurred to me that adding more apps to contrib was kind of
a bad idea. I know "everyone" uses admin etc. but I was of the understanding
that contrib apps are optional apps for django but staticfiles doesn't seem
to be that way.  The core 'django.views.static.serve' and
'django.core.context_processors.media' are deprecated in favor of the
staticfiles equivalents in contrib. Is the idea that the contrib app is a
stepping stone to providing core functionality? i.e. It was put in contrib
to maintain backwards compatibility for at least enough time to satisfy the
deprecation policy? I'm also getting worried in general about adding more
and more functionality to Django that doesn't really *need* to be there.

On a seperate topic, it occurred to me that if you wanted to use the same
backend for your STATIC_STORAGE as you use for DEFAULT_STORAGE then you'll
run into problems if you want to use different options for each. The docs
mention django_storages but you'll be hard pressed if you want to store your
static and user media in different buckets. It's one of the reasons I added
options to the constructor for the s3boto backend (I'm the current
maintainer) in django_storages and added a STATIC_STORAGE_KWARGS in my
branch of staticfiles on bitbucket.  Not sure it was the best solution, but
it works.

http://bitbucket.org/beproud/django-staticfiles/changeset/f6cdab87d63e

--
Ian

http://www.ianlewis.org/

-- 
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: #6375 -- Class Based Views: Opinions on commit plan

[Ian Lewis]

On Sat, Oct 16, 2010 at 1:31 PM, Yo-Yo Ma  wrote:

> Łukasz Rekucki,
>
> Thanks for the reply. I wasn't being cynical when I said:
>
> > If the API for this feature was not so intrinsically
> > obscure, it might be a more obvious choice to include it right away,
>
> What I meant was the design and implementation creates an unusable API
> by default. This is a sign that it's not quite ready. I don't suggest
> putting it off for another 2 years, but now that things are really
> starting to roll with Django, and more developers are getting added,
> it's worst time to start shoveling things in that a lot of people
> don't like, crippling production and evolution that could otherwise
> come very quickly now.
>
> > come help out!
>
> What do you call this. I don't see how any software developer could
> consider constructive criticism as anything other than helping out.
> Just about 90% of software development is in the mind (at least for
> me), and the other 10% is spent typing as fast as I can.
>

Are you arguing that the API is bad or are you arguing that features where
the API could change shouldn't land in trunk? If you are arguing for the
former then I think you'll need to be a lot more concrete about what you
don't like and how to fix it to really get traction at this point. If it's
the later then I can see the point, I know I have tracked trunk in the past
when developing projects (I know it's not a great idea), but I think the
merits of getting things tested properly outweighs the demerits in this case
so it's worth trying out. I wouldn't think the API will change much anyway.

-- 
Ian

http://www.ianlewis.org/

-- 
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: #6375 -- Class Based Views: Opinions on commit plan

[Ian Lewis]

On Fri, Oct 15, 2010 at 2:06 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> > There is this crazy idea im my mind to mark CBVs API as
> > "Beta" in 1.3 and put a big warning in the docs that it can change in
> > backwards-incompatible was in 1.4. A precedence to this would be
> > `databrowse`[1], but we could actually finish it this time ;).
>
> That thought has occurred to me in the past. My concern is how we
> manage such an idea as a project. Backwards compatibility is a big
> deal, and one of Django's big selling points IMHO.
>
> So - the question becomes how can we introduce a new feature, but give
> people fair warning that they're using a feature that is subject to
> change? Python's 'from __future__' is a really good approach to this,
> IMHO -- i.e., an explicit opt-in to new features. There might be some
> room to explore this sort of idea for Django.
>
> However, this isn't a decision we need to make right now. If we land
> what we have, we can fiddle with it until the RC comes out; if we are
> getting to that point and we're making API changes, we can look at our
> options for providing adequate warnings.


I'm with Russ here. I'd be wary of introducing exceptions to the current
backwards-compat policy. It's relatively simple, many people are familiar
with it, and I don't think it should change in surprising ways. The 'from
__future__' idea is compelling and I like it but I would avoid introducing
half baked features in a Django release. I expect most people like
frameworks to "work".

-- 
Ian

http://www.ianlewis.org/

-- 
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: Translating Django's documentation

[Ian Lewis]

On Wed, Oct 13, 2010 at 4:58 PM, Jannis Leidel  wrote:

>
> > The current state-of-the-art is in the somewhat-badly-named
> > "community_redux" branch on my Github account:
> > http://github.com/jacobian/djangoproject.com/tree/community_redux, and
> > I would *gladly* take input and/or patches into how to start adding
> > multi-language support.
>
> While this is definitely a big +1 from me, I've already worked on updating
> the djangoproject.com code to support Sphinx' latest i18n features before
> and during Djangocon and only need to incorporate them in the new site code.


Do you have this uploaded somewhere where I can take a look at it? We will
probably be doing a translation sprint here around the end of next month and
I'd like to have an idea what might be required. There is going to be some
work incorporating the current Japanese translation into the site I'm sure.


> > There are some tricky problems to solve -- most notably the issue of
> > tracking which bits of content have been translated into which
> > languages and how up-to-date with the original English docs those are
>
> Indeed, this is actually solved by recent changes in the Sphinx (versioning
> and i18n support), that'll be part of the 1.1 release (Yay!). From what I
> understand there will also be an API that would allow us display sensible
> information about the accuracy of each translation, since changes to content
> blocks are tracked internally. Whether we should adopt the use of Sphinx
> websupport module to lower the efforts on our site is yet to be determined
> though.
>

I'll take a look at the i18n support in Sphinx 1.1. I assume it's in trunk
now as it's not released.

-- 
Ian

http://www.ianlewis.org/

-- 
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: Translating Django's documentation

[Ian Lewis]

On Wed, Oct 13, 2010 at 11:32 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> On Wed, Oct 13, 2010 at 10:20 AM, Ian Lewis  wrote:
> > Hi all,
> > I am a member of the Japanese Django community which is maintaining a
> > somewhat(read very) outdated version of the Django documentation
> > here: http://djangoproject.jp/doc/ja/1.0/
> > I'm trying to kickstart a project to update the documentation and in
> looking
> > around I noticed that on Django's homepage the documentation's URL
> includes
> > the language code. I was wondering, is there is an official way to submit
> > translations for Django's documentation? Is there currently a way to link
> or
> > help direct users from Django's site to the proper resources in the their
> > language?
>
> Not *quite* yet.
>
> The URL you've noticed is forward planning -- translations of the
> documentation have always been on the nice-to-have list, so we've
> planned for future expansion. At the moment, however, there is only
> the english translation, and we don't really have the facilities to
> handle alternate languages.
>
> There are a bunch of modifications that we want to make to
> docs.djangoproject.com, and providing support for other languages is
> part of those improvements. Some recent additions to Sphinx should
> make it much easier to manage this process.
>
> If you want to help out set up the infrastructure to make this happen,
> there was a recent call for volunteers on the Django Software
> Foundation's members and volunteers list [1]; if you jump on that list
> now, it's not too late to register your interest in helping out (ok..
> the deadline has passed, but we're not going to pass up any offer of
> volunteer help).
>
> [1] http://groups.google.com/group/dsf-members
>
> Yours,
> Russ Magee %-)



Ok,  I wasn't aware of the other list.  I send a request for membership.

Thanks,


-- 
Ian

http://www.ianlewis.org/

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

Translating Django's documentation

[Ian Lewis]

Hi all,

I am a member of the Japanese Django community which is maintaining a
somewhat(read very) outdated version of the Django documentation here:
http://djangoproject.jp/doc/ja/1.0/

I'm trying to kickstart a project to
update the documentation and in looking around I noticed that on Django's
homepage the documentation's URL includes the language code. I was
wondering, is there is an official way to submit translations for Django's
documentation? Is there currently a way to link or help direct users from
Django's site to the proper resources in the their language?

-- 
Ian

http://www.ianlewis.org/

-- 
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: #6735 -- Class based generic views: call for comment

[Ian Lewis]

On Sun, Oct 3, 2010 at 8:02 PM, Russell Keith-Magee
 wrote:
>> Other frameworks seem have View/Handler instances per request, such as
>> appengine's webapp so there is some precedent for creating an instance
>> per request.
>>
>> http://code.google.com/appengine/docs/python/gettingstarted/handlingforms.html
>
> I don't think you'll find any argument that having an instance per
> request would solve all the problems that this thread has described.
> The issue is how to declare a view that is able to be instantiated on
> a instance-per-request basis while simultaneously allowing decorators
> to be easily wrapped around that view.

I was sort of referring to the __new__() method you are describing to
allow state to be stored on self.

A class instance that can be wrapped by a decorator to me is simply a
callable instance and people are just
going to have to get used to the idea that self can't be modified
safely. Anything else is a bad hack that will likely
cause even more headaches down the road.

That said, even Django itself has code that falls victim to storing
state on self in a callable class based view (See:
django.contrib.formtools.preview.FormPreview). So I can imagine many
people will be confused, but it is what it is.

-- 
Ian

http://www.ianlewis.org/

-- 
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: #6735 -- Class based generic views: call for comment

[Ian Lewis]

2010/10/3 Łukasz Rekucki :
> On 3 October 2010 06:12, Ian Lewis  wrote:
>> Flask seems to do it the callable singleton way:
>>
>> http://flask.pocoo.org/docs/patterns/lazyloading/
>>
> I never used Flask, so I might be missing something, but I don't see a
> singleton view instance here - just a proxy, that imports a function
> on first use. Although functions are singleton by their nature.

I'm not a flask expert either but under "Loading Late" there is a
LazyView which I believe is just a callable object.

And later under that he adds a LazyView instance to a url rule so I think it's
simply a "view is a callable" pattern.

-- 
Ian

http://www.ianlewis.org/

-- 
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: #6735 -- Class based generic views: call for comment

[Ian Lewis]

On Sun, Oct 3, 2010 at 11:20 AM, Russell Keith-Magee
 wrote:
>> The issue is not only the frequency of failure, but how explicit/clear
>> it is. The failure here is so obscure and difficult to track down, it
>> is likely to generate an outsize support burden. In contrast, raising
>> an error on assigning to self can be completely explicit; no hours of
>> painful and confusing debugging necessary.
>>
>> Let's also be clear to distinguish "just document that you don't store
>> state on self" vs "raise an error if you set an attribute on self."
>> These are proposals with very different characteristics in terms of
>> likely confusion and support burden.
>
> Agreed. The "just document" approach is a non-starter; the 'error when
> you set attribute on self' is at least a technically viable option.
>
> My problem with the error-based approach is entirely conceptual -- it
> feels to me like throwing the baby out with the bathwater. I'm having
> a lot of trouble with the idea that class instances have state in
> every other Python class instance, and if we introduce an API that
> physically prohibits instance state that -- no matter how good the
> technical reasoning --  we're going to:
>
>  * Cause confusion amongst new users as to why this seemingly obvious
> thing can't be done
>
>  * Ignore the legitimate occasions where using state is a useful
> architectural approach.

While I'm in the "one singleton view instance is best" camp and think
that storing some state on the request and some on the view is a bit
gross, I understand Russell's arguments. New users are simply going to
save stuff on self no matter how much we complain, document etc. It's
simply a reality that likely can't be helped much.

Other frameworks seem have View/Handler instances per request, such as
appengine's webapp so there is some precedent for creating an instance
per request.

http://code.google.com/appengine/docs/python/gettingstarted/handlingforms.html

Flask seems to do it the callable singleton way:

http://flask.pocoo.org/docs/patterns/lazyloading/

Is there any precedent in other frameworks for doing it the singleton
way? Talking a bit about how other frameworks/libraries do this might
be a good idea to figure out what Joe User is likely to do.

-- 
Ian

http://www.ianlewis.org/

-- 
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: #6735 -- Class based generic views: call for comment

[Ian Lewis]

On Sat, Oct 2, 2010 at 11:37 AM, David P. Novakovic
 wrote:
> By this reasoning, when you add extra helper methods to your class,
> which is the reason for OO views, you need to add/use the data those
> methods will modify to the request object? That just doesn't make
> sense to me at all. It reminds me of the "Feature Envy" code smell..

I'm not sure I understand your comment. Are you complaining about having to pass
the request object around? I think having a helper view add or modify
data on the request
object is more than reasonable. Please also explain to me what you are
meaning by "Feature Envy".

class ViewClass(...):
...
def helper_method(self, request):
request.somedata = "data"
...

I think there might be a nicer way to do this like adding a state
dictionary to the request so that
there was a place to put request state that's not directly on the
request, but that feels like
bikeshedding at this point, if I used the term correctly.

As Alex has said earlier, this is the way the Admin has always worked
and it works ok IMHO so it makes
sense to do something similar with non-admin class based views.

-- 
Ian

http://www.ianlewis.org/

-- 
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: #6735 -- Class based generic views: call for comment

[Ian Lewis]

On Sat, Oct 2, 2010 at 12:20 AM, Alex Gaynor  wrote:
> Not really.  The big win from a class-based view is not being able to
> store state, you can do that with local variables, it's being able to
> override parts of the behavior without needing to rewrite the entire
> view, or add 101 parameters.

Agreed. There is already an object to store state per request. It's
the request object. It's there for a reason. Adding data to the
class instance would be like adding data to the view function (like
view_function.data = "spam"). No one would agree that's a good idea.

> We don't have that documentation for the admin.  Either we need it, or
> our users are a little bit smarter than we're giving them credit.

Playing devil's advocate, the admin may not be accessed as much as the
main site, so bugs involving concurrent access may not crop up as much
or be prioritized lower depending on the organization creating the
website.

-- 
Ian

http://www.ianlewis.org/

-- 
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: #12012 Logging: request for comments

[Ian Lewis]

Not sure I ever understood what Bikeshedding means properly, but fair
enough. My point was more to break it up the logging level by 2/3/400
classes of HTTP status codes and log each status code class with the
same logging level.

On Wed, Sep 29, 2010 at 1:06 AM, Alex Gaynor  wrote:
> I don't see how a 302 because someone posted something is any less debug
> thann the 200 to serve thhhe get.
>
> Bikesheddinngly yours,
> Alex
>
> On Sep 28, 2010 11:45 AM, "Ian Lewis"  wrote:
>
> Hi,
>
> On Tue, Sep 28, 2010 at 9:19 AM, Nick Phillips
>  wrote:
>> I'm worried by ...
>
> I'm split on this myself but I think making all 400 level responses warnings
> would keep things consistent and help find potential security issues easier.
>
> Something like
>
> 5xx = error
> 4xx = warning
> 3xx = info
> 2xx (>300) = debug
>
> would be very easy to understand and the desired request logging is easy
> to set up using logging levels.
>
> --
> Ian
>
> http://www.ianlewis.org/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" g...
>
> --
> 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.
>



-- 
Ian

http://www.ianlewis.org/

-- 
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: #12012 Logging: request for comments

[Ian Lewis]

Hi,

On Tue, Sep 28, 2010 at 9:19 AM, Nick Phillips
 wrote:
> I'm worried by the use of "warning" for all 4xx statuses. I think it
> still makes sense to use the "original" syslog level definitions[*] as a
> guide, and on there I'd suggest that some 4xx statuses would merit
> "Info", some "Notice", and maybe one or two "Warning". "Notice" not
> being included in Python's default logging, I guess that means I'd split
> them between "Info" and "Warning".
>
> My view is that the main use of these logs to me is to help me see when
> someone is doing Bad Things (or trying to) to my system. I would be
> wanting anything that indicated a targeted exploration of my server to
> show up as "Warning", and anything that's most likely a random script
> kiddie to be "Info". That certainly puts 404 in as "Info"; I see so many
> hits looking for e.g. poorly-configured phpmyadmin installations, that
> 404s would swamp anything that I really needed to be looking at.

I'm split on this myself but I think making all 400 level responses warnings
would keep things consistent and help find potential security issues easier.

Something like

5xx = error
4xx = warning
3xx = info
2xx (>300) = debug

would be very easy to understand and the desired request logging is easy
to set up using logging levels.

-- 
Ian

http://www.ianlewis.org/

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

[Ian Lewis]

On Sun, Jun 20, 2010 at 12:19 PM, Russell Keith-Magee
 wrote:
> On Sun, Jun 20, 2010 at 4:59 AM, David North
>  wrote:
>> On 28/05/2010 16:48, Russell Keith-Magee wrote:
>> * They have to be sprinkled all over the place (or in a lot of places, at
>> least) rather than the logging aspect of the application being more
>> centrally defined, which makes it hard to ensure they're consistently where
>> they ought to be
>
> Well.. logging is *always* going to be sprinkled all over the place -
> at some point, you have to be able to say "after you wibble the
> doo-gadget, write X to the log", and the only sensible place to this
> is somewhere in doo_gadget.wibble().

Django should use it's own logger or loggers (for different logical
componets? ORM, Templating etc.) so that Django's internal logging can
be controlled or ignored via logging handlers.

>> One way round this is to use an aspect-oriented approach, which is nice and
>> easy in Python - e.g. http://www.hackersinshape.net/archives/67 - this would
>> allow us to drop decorators onto functions we want logging around, and
>> possibly even do so dynamically for maximum flexibility and ease of
>> maintenance.
>
> I can see how aspect orientation is an alternative approach to the
> central control problem, but I really don't see how it fixes the
> 'sprinkling' problem - instead of logging calls sprinkled everywhere,
> you have metaclasses that automatically sprinkle decorators on
> methods. This gives you less fidelity (since you can only log at the
> enter/exit method level), and adds magic (since you need to understand
> how the metaclass is works in order to understand what is being
> logged).

Direct logging is simpler and would work for most use cases. The
aspect oriented approach would be useful as a separate library or
module separate from Django IMHO.


I've used Zain's jogging for a while as a nice way of using python's
logging module with Django. It might be worthwhile to check it out and
see what it's doing for reference.

http://github.com/zain/jogging

Ian


-- 
===
株式会社ビープラウド  イアン・ルイス
〒150-0021
東京都渋谷区恵比寿西2-3-2　NSビル6階
email: ianmle...@beproud.jp
TEL:03-6416-9836
FAX:03-6416-9837
http://www.beproud.jp/
===

-- 
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: Class based generic views in 1.3?

[Ian Lewis]

The example he provided isn't terribly good but you don't need an view
instance per request (the example will work unless you start adding
stuff to self or overwriting self.qs etc). Only shared state is stored
at the class level and view customization is done at the class
instance level as well. That state shouldn't change.

Attaching all kinds of stuff to self tends to depend on the order of
the methods called and allows for some ugly coding styles. In that
case the slightly strange idea of merging the request and the view by
extending HttpRequest starts to make sense since otherwise you would
have some state on the request object (like the user etc. as it is
now) and some state on the view object.

That said, both extending HttpRequest and using __new__ seem like a
hacks to me. Personally the idea of a view being a callable class
instance or method is simple and flexable enough to handle any use
cases we are talking about. You just have to think of self as the
*view* rather than a thread safe request because that's what it is.

Having a view object per request makes no sense. You should have a
request object per request.  It is largely a result of wanting the
convenience of being able to write sloppy code that writes all kinds
of state to self rather than a technical necessity.

Ian

On Thursday, June 17, 2010, Waldemar Kornewald  wrote:
> On Thu, Jun 17, 2010 at 1:42 PM, Patryk Zawadzki  wrote:
>> On Thu, Jun 17, 2010 at 1:20 PM, Waldemar Kornewald
>>  wrote:
>>> Please take a deeper look at his code. He doesn't use __init__. He
>>> uses __new__, so each request gets his own View instance.
>>>
>>> Instead of
>>>
>>> aa = AwesomeAdd()
>>> foo = aa(3, 5)
>>>
>>> the __new__-based approach allows to do this:
>>>
>>> foo = AwesomeAdd(3, 5)
>>>
>>> IOW, the "constructor" directly returns an HttpResponse (foo) instead
>>> of an AwesomeAdd instance.
>>
>> There is no difference between using __init__ and __new__ as long as
>> you treat the instance as a junkyard for temporary variables. If done
>> properly, class-based views do _not_ need a separate instance for each
>> request.
>>
>> Here's an example of a thread-safe view that works happily with just
>> one instance:
>>
>>  8< 
>>
>> class MyView(object):
>>def __init__(self, queryset, template='bar.html'):
>>self.qs = queryset
>>self.template = template
>>
>>def __call__(self, request, id):
>>instance = get_object_or_404(self.qs, id=id)
>>return direct_to_template(request, self.template, {'object': 
>> instance})
>>
>> # ...
>>
>>url(r'^foo/(?P\d+)/', MyView(queryset=Foo.objects.all(),
>> template='foo.html')),
>
> This is not at all thread-safe because all requests share the same
> view instance and thus the same state. Shared state is not thread-safe
> (unless you introduce some locking mechanism which is not an option
> here). Thread-safety can only be guaranteed if every thread has its
> own state. In other words, every request needs his own View instance.
>
> Bye,
> Waldemar Kornewald
>
> --
> 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.
>
>

-- 
===
株式会社ビープラウド  イアン・ルイス
〒150-0021
東京都渋谷区恵比寿西2-3-2　NSビル6階
email: ianmle...@beproud.jp
TEL:03-6416-9836
FAX:03-6416-9837
http://www.beproud.jp/
===

-- 
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: Django Transaction Integrity

[Ian Lewis]

> Yes: we're talking about Django's transaction management layer (that is, the
> code in django.db.transaction), which controls how Python-level transaction
> blocks map to SQL transactions.
>
> The original email and writeup has a full explanation. :)
>

Yes. What I was getting at is that django's transaction management
layer is a layer over top of the database's own transaction management
not a full transaction layer implemented at the application level. In
any case the underlying database doesn't support nested transactions
in the case of MySQL. Starting a transaction within a transaction does
not subsume the current transaction. It does an implicit commit,
ending the current transaction and starts a new top level transaction.

In any case it's probably not worth talking much more about it since
you can probably implement the functionality using savepoints at least
with InnoDB. But I did want to bring up that there are database
portability implications here.

-- 
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: Django Transaction Integrity

[Ian Lewis]

I should probably be more specific. Without using savepoints nested
transaction functionality couldn't be achieved with MySQL (and only
with InnoDB). START TRANSACTION does an implicit commit so the
previous transaction is not subsumed.

I suppose that savepoint based functionality could be implemented for
MySQL in lieu of nested transactions though.

See: http://dev.mysql.com/doc/refman/5.0/en/implicit-commit.html

2010/5/18 Ian Lewis :
> Am I missing something? Are we talking about doing some kind of
> transaction management at the application level? If not then it's
> worth noting that in MySQL you cannot begin a transaction twice
> without commiting or rolling back. i.e. nested transactions are not
> supported.
>
> On Tue, May 18, 2010 at 1:05 AM, Piet Delport  wrote:
>> 2010/5/17 Ian Lewis :
>>>
>>> I suppose that it's worth mentioning that any support for nested
>>> transactions will not be portable to different databases (particularly
>>> MySQL) and probably would need to be documented accordingly.
>>
>> How do you mean?
>>
>> Django-level transaction block nesting is portable to any database that
>> supports transactions: The top-level transaction subsumes nested
>> transactional blocks.
>>
>> If you are referring to SQL savepoints, supporting them is entirely
>> optional: nested transaction blocks do not depend on it in any way.
>> Savepoints are more like an optional performance optimization than
>> anything else, and just give applications the option of doing
>> finer-grained failure recovery in certain cases without changing the
>> meaning of transactional blocks. (The proposal above only mentions
>> savepoints for completeness, and because support for them would be
>> natural to integrate.)
>>
>> --
>> 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.
>>
>>
>
>
>
> --
> ===
> 株式会社ビープラウド  イアン・ルイス
> 〒150-0021
> 東京都渋谷区恵比寿西2-3-2　NSビル6階
> email: ianmle...@beproud.jp
> TEL:03-6416-9836
> FAX:03-6416-9837
> http://www.beproud.jp/
> ===
>



-- 
===
株式会社ビープラウド  イアン・ルイス
〒150-0021
東京都渋谷区恵比寿西2-3-2　NSビル6階
email: ianmle...@beproud.jp
TEL:03-6416-9836
FAX:03-6416-9837
http://www.beproud.jp/
===

-- 
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: Django Transaction Integrity

[Ian Lewis]

Am I missing something? Are we talking about doing some kind of
transaction management at the application level? If not then it's
worth noting that in MySQL you cannot begin a transaction twice
without commiting or rolling back. i.e. nested transactions are not
supported.

On Tue, May 18, 2010 at 1:05 AM, Piet Delport  wrote:
> 2010/5/17 Ian Lewis :
>>
>> I suppose that it's worth mentioning that any support for nested
>> transactions will not be portable to different databases (particularly
>> MySQL) and probably would need to be documented accordingly.
>
> How do you mean?
>
> Django-level transaction block nesting is portable to any database that
> supports transactions: The top-level transaction subsumes nested
> transactional blocks.
>
> If you are referring to SQL savepoints, supporting them is entirely
> optional: nested transaction blocks do not depend on it in any way.
> Savepoints are more like an optional performance optimization than
> anything else, and just give applications the option of doing
> finer-grained failure recovery in certain cases without changing the
> meaning of transactional blocks. (The proposal above only mentions
> savepoints for completeness, and because support for them would be
> natural to integrate.)
>
> --
> 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.
>
>



-- 
===
株式会社ビープラウド  イアン・ルイス
〒150-0021
東京都渋谷区恵比寿西2-3-2　NSビル6階
email: ianmle...@beproud.jp
TEL:03-6416-9836
FAX:03-6416-9837
http://www.beproud.jp/
===

-- 
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: Django Transaction Integrity

[Ian Lewis]

I suppose that it's worth mentioning that any support for nested
transactions will not be portable to different databases (particularly
MySQL) and probably would need to be documented accordingly.

Ian

On Mon, May 17, 2010 at 7:50 PM, Piet Delport  wrote:
> Hi Russel, thanks for the response!
>
> On May 15, 12:47 pm, Russell Keith-Magee 
> wrote:
>>
>> By way of a brief explanation of why things are they way they are:
>>
>> Firstly, Django's history in journalism-based websites breeds a
>> history of high-volume reads, and low-volume, relatively simple
>> writes. As a result, the transactional requirements have been fairly
>> light.
>
> I suspected as much; the current implementation doesn't make much
> sense
> unless managed blocks were informally introduced at some point without
> being relied upon to be transactional. While this makes managed blocks
> are a bit of a white elephant at the moment (the only code that can
> use
> them safely is code that doesn't need to be transactional), it might
> also be a minor blessing in disguise, in that they are not used widely
> enough for the problem to have major impact (yet).
>
>> Secondly, although it's entirely legal Python to apply
>> commit_on_success et al on arbitrary functions, the most common usage
>> has been to apply them to view functions, not arbitrary processing
>> functions. When these decorators are applied at the view level, you
>> don't get the nesting problems you describe.
>
> Right.
>
> (I'd like to note, though, that limiting commit_on_success to only
> top-level view functions is not enough to completely avoid this bug:
> for
> example, any usage of TransactionMiddleware will interact badly with
> it,
> especially if any intervening middleware uses the database.)
>
>> I haven't completely absorbed the specific proposals from your
>> document, but to put something into your mind for consideration:
>> backwards compatibility is a very large consideration here. We can't
>> arbitrarily change the way that transactions operate in existing code.
>> Any change that we make must be by way of adding new
>> functions/decorators, or by adding flags/modifiers to the existing
>> functions and decorators with default values that reproduce existing
>> behavior.
>
> Right, backward compatibility was big concern for me while
> investigating
> solutions to this. I believe that the proposed fix (making transaction
> blocks transactional as advertised) can be implemented in such a way
> that backward compatibility is preserved for almost all users: user
> code
> would not need to know anything about this change except that their
> currently-declared transaction blocks will operate correctly as
> intended, and no longer silently be vulnerable to broken edge cases as
> described above.
>
> In other words, the proposal is not to significantly change the
> meaning
> of transaction blocks, but rather to make them operate fully (instead
> of
> partially) as advertised: all code that currently uses them more or
> less
> as expected should continue to work as before, only more safely and
> correctly.
>
> Of course, this will need thorough review and testing, in case there
> turns out to be real cases where user code has somehow come to depend
> on
> the broken edge cases, but i can't offhandedly think of a scenario
> where
> this would easily happen.
>
>> So - thanks for your contribution. If you could kindly keep this warm
>> for a couple of weeks, we can revisit this properly once Django 1.3
>> development is in full swing. In the interim -- anything you can do to
>> turn this abstract set of proposals into some sample code, test cases,
>> or prototype implementation is certainly most welcome, and the more
>> concrete evidence you can present, the easier it will be to turn this
>> into a change in trunk.
>
> Thank you for your advice; this sounds like a good plan!
>
> I have informal tests for the scenarios described in the writeup, and
> will begin readying a prototype implementation as time allows.
>
> --
> 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.
>
>



-- 
===
株式会社ビープラウド  イアン・ルイス
〒150-0021
東京都渋谷区恵比寿西2-3-2　NSビル6階
email: ianmle...@beproud.jp
TEL:03-6416-9836
FAX:03-6416-9837
http://www.beproud.jp/
===

-- 
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: Adding signing (and signed cookies) to Django core

[Ian Lewis]

On Fri, Sep 25, 2009 at 4:46 AM, Simon Willison  wrote:
> This isn't so bad, since we already have a precedent for this in
> request.POST.get_list('foo'). request.COOKIES.get_signed(key) might be
> OK.

request.COOKIES.get_signed(key) makes the most sense to me since it's
clear you are dealing with cookies and as you said it looks something
like the request.POST object. Though it's a bit more verbose than
request.unsign_cookie(key), accessing cookies directly through the
request object looks wierd and unsign_cookie could be ambiguous.

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: Adding signing (and signed cookies) to Django core

[Ian Lewis]

On Fri, Sep 25, 2009 at 6:33 AM, Chris Beaven  wrote:
>
> +1 on the concept of a signing module.
>
> On Sep 25, 7:48 am, Marty Alchin  wrote:
>
>> The one downside to using get() directly, as opposed to an altogether
>> new method, is that get() doesn't raise a KeyError when a value
>> doesn't exist. That means if anyone's wrapping request.COOKIES[key] in
>> a try block and catching KeyError, changing to the new code is more
>> than just a one-liner.
>
> Adding my coat of paint to the shed...
>
> Rather than a "request.unsign_cookie" method, provide a
> "request.SIGNED_COOKIES" property (or perhaps alteratively,
> request.COOKIES.signed if the interface was useful enough to use
> across request.GET/POST too) containing a lazy dict-like object which
> only retrieves (correctly) signed cookies.
> This way you are using a similar interface, but it's obvious in code
> that you're only interested in signed ones.
>
> For example:
>
> # raises KeyError
> value = request.SIGNED_COOKIES['bad-cookie']
>
> # value == None
> value = request.SIGNED_COOKIES.get('bad-cookie')
>
> Personally, I don't see much point in specifically reporting on
> incorrectly signed cookies - imo they should just be treated as if
> they never existed. If someone really cared, they can look in
> request.COOKIES to see if the cookie was in there but not in
> SIGNED_COOKIES.

The problem is that you don't know which cookies are signed and which
aren't for the reasons posted earlier. So you don't know which cookies
to put in SIGNED_COOKIES and which to put in COOKIES unless accessing
COOKIES gives you raw values of ALL cookies and SIGNED_COOKIES
attempts to unsign ALL cookies. That seems really clunky.

You have to sign and unsign the cookies yourself in code which makes
the sign_cookie/unsign_cookie API make sense.

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