Re: [GSOC 2012] Customizable serialization
I am quite interested in this, as most of my coding work has been developing APIs that get consumed by non-web-browser software. Lately, I've taken the approach that a Form is the appropriate tool to use for (de)serialisation: it's already used extensively by the template rendering (which is indeed serialisation of data). The workflow I use is: Model instance -> Model form -> pre-serialised (python) data structure -> serialised data That way, the only bits of code that are required are the pre-serialiser: which takes a Form object (possibly a ModelForm, but not necessarily), and returns a python dict. This handles the nested pre-serialisation, for instance. Then, for each serialisation type, you need a serialiser that converts that dict into the relevant type. For vanilla JSON, this is simply json.dumps(), and it is trivial to get a simple XML output too. As for going back the other way: the data that comes in can be deserialised, and then passed directly to the form(), just as you would with request.POST. Matt. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/12mcu7EJmDQJ. 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
On Mon, Apr 2, 2012 at 11:04 PM, Donald Stufft wrote: > Identity doesn't have anything to do with automatically dispatching > users. All it is is a unique identifier. That's all this proposal honestly > enforces that your users have. Some single piece of identifiable data that > can be used to differentiate. This could be a username, or an email > address. It could be a random string. Anything you want. > > In your example you might have a TwitterProfile that provides 2 fields, > "authenticated_by_twitter" and "twitter username". Then if you want to > check how a person authenticated to your site, you'd merely check if > user.data["authenticated_by_twitter"] was True. The identifier doesn't need > to have that data codified in it, (but it could!) and I honestly do not > think the statement "all users must have 1 single string of any length that > uniquely identifies them" is that big of a burden. > Perhaps I am more pessimistic than you, but I think it will quickly get out of hand. I mean, what reasonable developer would look at the user model as Jacob proposes, and wouldn't at least consider, "Well, I could make my own profile and ask everyone to add my app to AUTH_PROFILES and be magically joined on all User queries, or I could use the arbitrary length guaranteed-unique varchar to encode a whole mess of twitter credentials. I think I will choose option #2?" Then as soon as everyone does that and facebook, twitter, browserid, and plain emails all share the same namespace, we open up the same whole can of worms that we get with cache keys, except now failures to manage things properly manifest themselves as security holes in basic authentication instead of cache collisions. Best, Alex Ogier -- 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
On Monday, April 2, 2012 at 10:56 PM, Alex Ogier wrote: > I realize that arguing with a BDFL might get me nowhere, but I don't think > that multi-profile + select_related + proxy attributes on the user model is > the proper approach for users going forward. The proposal makes some basic > sense as an incremental improvement on the current status quo of a built-in > user with fixed 30-character identifier and single one-to-one profile. But in > the larger scheme of things it moves further in the wrong direction, in my > opinion, towards a model that addresses people's specific 80% questions > (email-as-identifier, packageable extra fields) but not the general > best-of-all-worlds mechanisms. > > Consider the other batteries-included frameworks out there. I think the three > biggest ones are probably Ruby on Rails, ASP.NET (http://ASP.NET) MVC, and > Play Framework. Something all three have in common, something I think would > be valuable for Django, is that their User identity is absent, and > authentication and authorization modules are added to a developer-created > User model ad-hoc. I think it's fair to say, the ecosystem of third-party > authentication mechanisms surrounding all three of these competitor > frameworks is MUCH healthier than Django's, for the simple reason that it is > much more flexible and sane to define your own user and plug in an > authentication module then it is to plug authentication into a fixed user > model that magically proxies back (even one as simple as a varchar identity + > password). > > The basic idea is that "authentication" is something that can be provided for > any model you like. When a user authenticates, they are providing some sort > of authentication token to your project that proves they are who they say > they are, and as a developer you are free to attach this authentication token > to *whatever you like,* not only contrib.auth.models.User. There is a rich > ecosystem of third party authentication apps for our competitor frameworks > that all work on this principle. They can provide authentication flows that > bounce the user back and forth to twitter.com (http://twitter.com), their > oauth provider, browserid, etc. and it is precisely because they don't demand > anything from a central object. Even something as simple as "all > user.identifiers that start with 'oauth2$' belong to our auth mechanism" > starts to open all sorts of security holes. What if someone wants to > authenticate by email+password OR by third party proof of email ownership (my > university has a mechanism like this)? Well, if someone can manage to register an account belonging to 'aog...@princeton.edu (mailto:aog...@princeton.edu)', maybe by triggering some obscure email change recovery form wizard or something, then suddenly they possess my account on Django. > > This is why I think the only sane long-term solution involves distinct and > pluggable authentication modules, and a concept of users that doesn't enforce > any brand of identity. The second stipulation is very important for social > reasons, if only to ensure that the path of least resistance for third-party > authentication doesn't involve trying to overload identity mechanisms for > disparate and incompatible purposes. > > JKM, you seem concerned that the notion of pluggable Users by necessity > involves magical settings. > > > I'm convinced that such an idea is ultimately a bad idea: it allows apps > > exert action at a distance over other apps. It would allow the idea of a > > user to completely change without any warning simply by modifying a setting. > > I am not convinced that this must be so. Asking a developer to write their > own User model is not the same thing as automagically reshaping > contrib.auth.models.User based on settings. A developer-defined notion of > identity is a thing that should be codified in software by constructing a > model. This community seems fixed on the idea that whatever model the > developer comes up with to satisfy the bizarre constraints of his particular > website, it must eventually be mounted at auth.User lest the world come > crashing down as foreign keys break, middleware throws exceptions and > California slides into the pacific ocean. > > Nearly every other framework out there does this the opposite way: to > authenticate with a third-party service, you add fields to your identity > model to support whatever credentials are necessary. Not the other way round, > where auth modules define models that have OneToOneFields to auth.User that > uses an AUTH_PROFILES setting to magically proxy back. > > I get that Django's core is very accustomed to the relational database mode > of thinking: "If a User might own a Twitter handle, then let's create a table > of twitter handles in the twitter-auth app, and foreign key back to the > default User model". It's really not that bad to go the other way for a > moment, and
Re: auth.user refactor: the profile aproach
On 03/04/2012, at 8:35 AM, Jacob Kaplan-Moss wrote:
> Hi folks --
>
> I've written up a proposal for how *I* would like to address refactoring
> auth.user: https://gist.github.com/2245327.
>
> In essence, this does two things:
>
> * Vastly "prunes" the required fields on auth.user. The only things left are
> an "identifier" (which could be username, email, url, uuid, whatever), and a
> password.
> * Introduces a new "profile" system that provides a way to contribute extra
> related fields. Multiple profiles are supported, along with some syntactic
> sugar for dealing with multiple profiles in a reasonably reusable way.
>
> And that's about it. I'm deliberately trying to find a middle ground between
> "do the minimum to allow people to move on" and "throw out and rewrite
> django.contrib.auth entirely". I'm not expecting everyone to be thrilled by
> this idea, but I'm hoping that this is "Good Enough" for almost everyone.
>
> For more please see the document. Please do try to read the whole thing: I've
> had a few rounds of feedback incorporated already, and there's even an FAQ at
> the end.
I've added a summary of this option to the wiki:
https://code.djangoproject.com/wiki/ContribAuthImprovements#Solution5:Profile-basedsingleusermodel
As always, feel free to correct/update as necessary.
>From my reading of the proposal, here are some questions/edge cases. For some
>of these questions, I fully expect the answer may be "You just can't do that";
>however, given that they're plausible edge cases, it's worth being explicit
>about what we're aiming at.
* Auto-profile creation:
What if my profile is:
class MyProfile(Profile):
first_name = CharField(max_length=100)
last_name = CharField(max_length=100)
i.e., first_name and last_name are both required fields. How does the profile
get automatically instantiated in this case? Doesn't the auto-instantiation of
profiles essentially mean that there can be no required fields on a profile
(or, at least, on an auto-instantiated profile)?
* Regarding AUTH_PROFILE and collisions:
What if I have 2+ profiles, but no clear order of precedence? e.g.,
class MyProfile1(Profile):
name = CharField()
email = EmailField()
color = CharField()
class MyProfile2(Profile):
name = CharField(unique=True)
email = EmailField()
age = IntegerField()
Lets say that for some internal logic reason for profile processing, I need
both email and age on MyProfile2, but name from MyProfile1. Under these
circumstances, there's no way I can specify a single AUTH_PROFILE ordering that
will satisfy my requirements. Is this a case where I have to resort to explicit
naming?
Or, alternatively, should we be treating AUTH_PROFILE as a mechanism for purely
specifying the resolution to specific lookup problems? i.e., instead of just
specifying an order, we specify which model we want ambiguous fields to come
from:
AUTH_PROFILE_LOOKUP = {
'name': 'myapp1.MyProfile1',
'email': 'myapp1.MyProfile2',
'color': 'myapp1.MyProfile2',
}
That way, if a field is unambiguous, it's returned from whatever model provides
it; if a field is ambiguous, we return the one specified; and if the ambiguity
isn't resolved, we return a KeyError (or catch this case as a validation error
on startup).
* Required fields and AUTH_PROFILE
Combining the previous two points; what if MyProfile2 has a required field, but
it isn't a field selected by data[]? e.g, in the previous example,
MyProfile2.name is a required unique field; but if it isn't instantiated with
useful data, the profile instances can't exist.
== Commentary ==
For me, the previous three edge cases essentially point to the fact that there
can ultimately only be 1 profile for "core" user information. There will almost
certainly be uses for multiple profiles (e.g., to store OpenID credentials) --
but then, this is already the case (I've got more than one project in the wild
with multiple "UserProfile" objects, without using AUTH_USER_PROFILE). However,
as soon as there are overlaps between profiles, you're going to end up with
partially populated profiles, and eventually someone will write a 'unified'
profile model for each project that doesn't have the overlap ...
... at which point, we've essentially arrived at a swappable User model, just
with a required join to get profile data, and a bunch of magic attributes and
ORM properties to hide the fact that the join exists.
I understand Django's history has examples where swappable models caused
problems that we don't want to revisit. However, as I understand it, these
problems were largely caused by the fact that it was *easy* to accidentally
swap out a model, and that change wouldn't be effectively communicated to other
developers on the same codebase until the magic smoke escaped.
It's also worth pointing out that the problems with swappable models aren't
really avoided by the profile-based approach. If I've got a pro
Re: auth.user refactor: the profile aproach
On 04/02/2012 06:35 PM, Jacob Kaplan-Moss wrote: > I've written up a proposal for how *I* would like to address refactoring > auth.user: https://gist.github.com/2245327. +1 from me. One minorish nit: I think that "in the face of ambiguity, refuse the temptation to guess" should apply equally to reading or writing user.data, and that there shouldn't be an awkward discrepancy between reading and writing. Thus, if you've got multiple profiles with overlapping attributes (the less-common case), you need to be explicit with AUTH_PROFILES in order to either read or write the overlapping keys via user.data (but writing is then allowed). In the common case of no overlapping keys, of course, you don't have to worry about AUTH_PROFILES. Carl signature.asc Description: OpenPGP digital signature
Re: auth.user refactor: the profile aproach
I realize that arguing with a BDFL might get me nowhere, but I don't think that multi-profile + select_related + proxy attributes on the user model is the proper approach for users going forward. The proposal makes some basic sense as an incremental improvement on the current status quo of a built-in user with fixed 30-character identifier and single one-to-one profile. But in the larger scheme of things it moves further in the wrong direction, in my opinion, towards a model that addresses people's specific 80% questions (email-as-identifier, packageable extra fields) but not the general best-of-all-worlds mechanisms. Consider the other batteries-included frameworks out there. I think the three biggest ones are probably Ruby on Rails, ASP.NET MVC, and Play Framework. Something all three have in common, something I think would be valuable for Django, is that their User identity is absent, and authentication and authorization modules are added to a developer-created User model ad-hoc. I think it's fair to say, the ecosystem of third-party authentication mechanisms surrounding all three of these competitor frameworks is MUCH healthier than Django's, for the simple reason that it is much more flexible and sane to define your own user and plug in an authentication module then it is to plug authentication into a fixed user model that magically proxies back (even one as simple as a varchar identity + password). The basic idea is that "authentication" is something that can be provided for any model you like. When a user authenticates, they are providing some sort of authentication token to your project that proves they are who they say they are, and as a developer you are free to attach this authentication token to *whatever you like,* not only contrib.auth.models.User. There is a rich ecosystem of third party authentication apps for our competitor frameworks that all work on this principle. They can provide authentication flows that bounce the user back and forth to twitter.com, their oauth provider, browserid, etc. and it is precisely because they don't demand anything from a central object. Even something as simple as "all user.identifiers that start with 'oauth2$' belong to our auth mechanism" starts to open all sorts of security holes. What if someone wants to authenticate by email+password OR by third party proof of email ownership (my university has a mechanism like this)? Well, if someone can manage to register an account belonging to 'aog...@princeton.edu', maybe by triggering some obscure email change recovery form wizard or something, then suddenly they possess my account on Django. This is why I think the only sane long-term solution involves distinct and pluggable authentication modules, and a concept of users that doesn't enforce any brand of identity. The second stipulation is very important for social reasons, if only to ensure that the path of least resistance for third-party authentication doesn't involve trying to overload identity mechanisms for disparate and incompatible purposes. JKM, you seem concerned that the notion of pluggable Users by necessity involves magical settings. I'm convinced that such an idea is ultimately a bad idea: it allows apps > exert action at a distance over other apps. It would allow the idea of a > user to completely change without any warning simply by modifying a setting. I am not convinced that this must be so. Asking a developer to write their own User model is not the same thing as automagically reshaping contrib.auth.models.User based on settings. A developer-defined notion of identity is a thing that should be codified in software by constructing a model. This community seems fixed on the idea that whatever model the developer comes up with to satisfy the bizarre constraints of his particular website, it must eventually be mounted at auth.User lest the world come crashing down as foreign keys break, middleware throws exceptions and California slides into the pacific ocean. Nearly every other framework out there does this the opposite way: to authenticate with a third-party service, you add fields to your identity model to support whatever credentials are necessary. Not the other way round, where auth modules define models that have OneToOneFields to auth.User that uses an AUTH_PROFILES setting to magically proxy back. I get that Django's core is very accustomed to the relational database mode of thinking: "If a User might own a Twitter handle, then let's create a table of twitter handles in the twitter-auth app, and foreign key back to the default User model". It's really not that bad to go the other way for a moment, and say "If a User might own a Twitter handle, then let's add a twitter_handle field to Users." The reason being that the latter is *so much more flexible*. You can simulate the first with the second, but not vice versa. Twitter-auth might not need its own table (in fact, it shouldn't need its own table). If you really wanted to, you cou
Re: auth.user refactor: the profile aproach
If we use __unicode__ (which i'm fine with) then it needs to follow the same resolution path as user.data[] does. On Monday, April 2, 2012 at 9:25 PM, Anssi Kääriäinen wrote: > On Apr 3, 4:20 am, Donald Stufft http://gmail.com)> > wrote: > > If i recall on IRC the decider was to just create a display field (e.g. > > user.data["display"]) that the default profiles can provide (and can be > > overridden by other profiles of course). > > > My problem with this is that for example where I work the display > field would contain '%s, %s (%s)' % (self.lastname, self.firstname, > self.empl_no). I would not like to do that data duplication. If the > 'display' can be a property then fine. But why not go directly for > __unicode__ in that case? > > - Anssi > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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
On Apr 3, 4:20 am, Donald Stufft wrote: > If i recall on IRC the decider was to just create a display field (e.g. > user.data["display"]) that the default profiles can provide (and can be > overridden by other profiles of course). My problem with this is that for example where I work the display field would contain '%s, %s (%s)' % (self.lastname, self.firstname, self.empl_no). I would not like to do that data duplication. If the 'display' can be a property then fine. But why not go directly for __unicode__ in that case? - Anssi -- 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
If i recall on IRC the decider was to just create a display field (e.g. user.data["display"]) that the default profiles can provide (and can be overridden by other profiles of course). On Monday, April 2, 2012 at 9:17 PM, Anssi Kääriäinen wrote: > On Apr 3, 3:35 am, Jacob Kaplan-Moss (http://jacobian.org)> wrote: > > Hi folks -- > > > > I've written up a proposal for how *I* would like to address refactoring > > auth.user:https://gist.github.com/2245327. > > > > In essence, this does two things: > > > > * Vastly "prunes" the required fields on auth.user. The only things left > > are an "identifier" (which could be username, email, url, uuid, whatever), > > and a password. > > * Introduces a new "profile" system that provides a way to contribute extra > > related fields. Multiple profiles are supported, along with some syntactic > > sugar for dealing with multiple profiles in a reasonably reusable way. > > > > And that's about it. I'm deliberately trying to find a middle ground > > between "do the minimum to allow people to move on" and "throw out and > > rewrite django.contrib.auth entirely". I'm not expecting everyone to be > > thrilled by this idea, but I'm hoping that this is "Good Enough" for almost > > everyone. > > > > For more please see the document. Please do try to read the whole thing: > > I've had a few rounds of feedback incorporated already, and there's even an > > FAQ at the end. > > > > I'm not using BDFL fiat here, at least not yet. This is a proposal, and I > > very much want to hear feedback, objections, and alternatives. I'm > > particularly interested in hearing from people who've got complicated auth > > needs and think this absolutely won't work for them. > > > > I *have* reviewed all the other proposals and I'm between -0 and -1 on all > > of them. This means that if you don't like my proposal, you'll probably > > have to come up with a complete *new* idea to have any chance of getting my > > vote. > > FWIW I am +1 on this proposal. This is assuming that forms, queryset > handling of the data and so on actually work correctly and nicely. I > don't see a blocker in those areas, but before the code is actually > written and tested it is impossible to say if there will be problems. > Devil is in the details and all that. > > I hope this will not result in hacks to allow .filter(data__) and so > on. I believe we should aim for as generic solutions as possible. If > we do hacks just for the User model, they _are_ going to cause > problems later on. Most of the features needed would be neat to have > regardless of the User refactor. Custom lookups per model/field for > example would be _really_ neat feature. The downside of aiming for > generic solutions is that we once again get into the situation where > User refactor is blocked by implementing foo, bar and baz before it. > > I believe this is the right way forward. Multiple profiles makes sense > in the SQL world, and in the NoSQL world you would just embed the > profiles into the User document. I don't believe performance will be a > problem in practice, at least as long as you don't add too many > different profiles to be loaded by default. The most common use case > will just get better support: you have user profile containing three > fields, and then you have all your local fields defined in one > profile. As now, you have profile + user, now they just model your > data properly. > > I don't see a proposal of how __unicode__ is going to be handled (the > Hello, UserName requirement). My proposal: go through the profiles in > the order they are defined, and pick the first one having __unicode__ > defined as the default __unicode__. If there is no such profile, > return identifier. > > - Anssi > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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
On Apr 3, 3:35 am, Jacob Kaplan-Moss wrote: > Hi folks -- > > I've written up a proposal for how *I* would like to address refactoring > auth.user:https://gist.github.com/2245327. > > In essence, this does two things: > > * Vastly "prunes" the required fields on auth.user. The only things left are > an "identifier" (which could be username, email, url, uuid, whatever), and a > password. > * Introduces a new "profile" system that provides a way to contribute extra > related fields. Multiple profiles are supported, along with some syntactic > sugar for dealing with multiple profiles in a reasonably reusable way. > > And that's about it. I'm deliberately trying to find a middle ground between > "do the minimum to allow people to move on" and "throw out and rewrite > django.contrib.auth entirely". I'm not expecting everyone to be thrilled by > this idea, but I'm hoping that this is "Good Enough" for almost everyone. > > For more please see the document. Please do try to read the whole thing: I've > had a few rounds of feedback incorporated already, and there's even an FAQ at > the end. > > I'm not using BDFL fiat here, at least not yet. This is a proposal, and I > very much want to hear feedback, objections, and alternatives. I'm > particularly interested in hearing from people who've got complicated auth > needs and think this absolutely won't work for them. > > I *have* reviewed all the other proposals and I'm between -0 and -1 on all of > them. This means that if you don't like my proposal, you'll probably have to > come up with a complete *new* idea to have any chance of getting my vote. FWIW I am +1 on this proposal. This is assuming that forms, queryset handling of the data and so on actually work correctly and nicely. I don't see a blocker in those areas, but before the code is actually written and tested it is impossible to say if there will be problems. Devil is in the details and all that. I hope this will not result in hacks to allow .filter(data__) and so on. I believe we should aim for as generic solutions as possible. If we do hacks just for the User model, they _are_ going to cause problems later on. Most of the features needed would be neat to have regardless of the User refactor. Custom lookups per model/field for example would be _really_ neat feature. The downside of aiming for generic solutions is that we once again get into the situation where User refactor is blocked by implementing foo, bar and baz before it. I believe this is the right way forward. Multiple profiles makes sense in the SQL world, and in the NoSQL world you would just embed the profiles into the User document. I don't believe performance will be a problem in practice, at least as long as you don't add too many different profiles to be loaded by default. The most common use case will just get better support: you have user profile containing three fields, and then you have all your local fields defined in one profile. As now, you have profile + user, now they just model your data properly. I don't see a proposal of how __unicode__ is going to be handled (the Hello, UserName requirement). My proposal: go through the profiles in the order they are defined, and pick the first one having __unicode__ defined as the default __unicode__. If there is no such profile, return identifier. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: [GSoC 2012] Schema Alteration API proposal
On 03/04/2012, at 5:06 AM, j4nu5 wrote: > Hi Russell, > > Thanks for the prompt reply. > > * You aren't ever going to eat your own dogfood. You're spending the GSoC > building an API that is intended for use with schema migration, but you're > explicitly not looking at any part of the migration process that would > actually use that API. How will we know that the API you build is actually > fit for the purpose it is intended? How do we know that the requirements of > "step 2" of schema migration will be met by your API? I'd almost prefer to > see more depth, and less breadth -- i.e., show me a fully functioning schema > migration stack on just one database, rather than a fully functioning API on > all databases that hasn't actually been shown to work in practice. > > 'Eating my own dogfood' to check whether my low level migration primitives > are actually *usable*, I believe can be done by: > 1. Developing a working fork of South to use these primitives as I mentioned > in my project goals, or > 2. Aiming for less 'breadth' and more 'depth', as you suggested. > > I did not opt for 2, since creating the '2nd level' of the migration > framework (the caller of the lower level API) is a huge beast by itself. Any > reasonable solution will have to take care of 'Pythonic' as well as > 'pseudo-SQL' migrations as discussed above. Not to mention taking care of > versioning + dependency management + backwards migrations. I am against the > development of a half baked and/or inconsistent 2nd level API layer. Trying > to fully develop such a solution even for one database will exceed the GSoC > timeline, in my humble opinion. Ok - there's two problems with what you've said here: 1) You don't make any reference in your schedule to implementing a "working fork of South". This isn't a trivial activity, so if you're planning on doing this, you should tell use how this is factored into your schedule. 2) You're making the assumption that you need to "fully develop" a solution. A proof of concept would be more than adequate. For example, in the 2010 GSoC, Alex Gaynor's project was split into two bits; a bunch of modifications to the core query engine, and a completely separate project, not intended for merging to trunk, that demonstrated that his core query changes would do what was necessary. You could take exactly the same approach here; don't try to delivery a fully functioning schema migration tool, just enough of a tool to demonstrate that your API is sufficient. > * It feels like there's a lot of padding in your schedule. > >- A week of discussion at the start >- 2 weeks for a "base" migration API >- 2.5 weeks to write documentation >- 2 "buffer" weeks > > Your project is proposing the development of a low level database API. While > this should certainly be documented, if it's not going to be "user facing", > the documentation requirements aren't as high. Also, because it's a low level > database API, I'm not sure what common tools will exist -- yet your schedule > estimates 1/6 of your overall time, and 1/3 of your active coding time, will > be spent building these common tools. Having 1/6 of your project schedule as > contingency is very generous; and you don't mention what you plan to look at > if you don't have to use that contingency. > > I think the problem is that the 1st part - development of a lower level > migrations API - is a little bit small for the GSoC timeline but the 2nd part > - the caller of the API - is way big for GSoC. As I said, I did not want to > create a half baked solution. Thats why the explicit skipping of 2nd level > and thus the *padding*. I am still open for discussion and suggestions > regarding this matter though. So, to summarize: What you're telling us is that you know, a-priori, that your project isn't 12 weeks of work. This doesn't give us a lot of incentive to pick up your proposal for the GSoC. We have an opportunity to get Google to pay for 12 weeks development. Given that we have that opportunity, why would we select a project that will only yield 6 weeks of output? The goal here isn't to pick a project, and then make it fit 12 weeks by any means necessary. It's to pick something that will actually be 12 weeks of work. A little contingency is fine, but if you start padding too much, your proposal isn't going to be taken seriously. My suggestion -- work out some small aspect of part 2 that you *can* deliver. Not necessarily the whole thing, but a skeleton, and try to delivery a fully fleshed out part on that skeleton. If you're smart about it, this can also double as your dogfood requirement. > * Your references to testing are a bit casual for my taste. From my > experience, testing schema migration code is hard. Normal view code and > utilities are easy to test -- you set up a test database, insert some data, > and check functionality. However, schema migration code is explicitly about >
auth.user refactor: the profile aproach
Hi folks -- I've written up a proposal for how *I* would like to address refactoring auth.user: https://gist.github.com/2245327. In essence, this does two things: * Vastly "prunes" the required fields on auth.user. The only things left are an "identifier" (which could be username, email, url, uuid, whatever), and a password. * Introduces a new "profile" system that provides a way to contribute extra related fields. Multiple profiles are supported, along with some syntactic sugar for dealing with multiple profiles in a reasonably reusable way. And that's about it. I'm deliberately trying to find a middle ground between "do the minimum to allow people to move on" and "throw out and rewrite django.contrib.auth entirely". I'm not expecting everyone to be thrilled by this idea, but I'm hoping that this is "Good Enough" for almost everyone. For more please see the document. Please do try to read the whole thing: I've had a few rounds of feedback incorporated already, and there's even an FAQ at the end. I'm not using BDFL fiat here, at least not yet. This is a proposal, and I very much want to hear feedback, objections, and alternatives. I'm particularly interested in hearing from people who've got complicated auth needs and think this absolutely won't work for them. I *have* reviewed all the other proposals and I'm between -0 and -1 on all of them. This means that if you don't like my proposal, you'll probably have to come up with a complete *new* idea to have any chance of getting my vote. Thanks! Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.4 default database required?
Thanks, I did look at it, it was the import of the Manager for the other shortcuts that was causing the issue. I'll try and file a bug for this. Paul On Apr 2, 2012, at 12:42 PM, Carl Meyer wrote: > On 04/02/2012 09:35 AM, Optimus Paul wrote: >> I've been running Django for quite a while without a "database", we >> use MongoDB, and it has worked well for us. We upgraded to 1.4 and >> found that suddenly a default database is required. Is there a reason >> for this? Or is this a bug? > > Preston has the right solution for this - delete your DATABASES setting > entirely. I think it would be best if an empty DATABASES setting had the > same effect, especially since that's how it was in 1.3 - if you'd be > willing to file a ticket for that, that'd be great. > >> We get the error when importing django.shortcuts.render_to_response, >> which doesn't seem like the kind of place a database connection would >> even be required. > > render_to_response doesn't require a database, but there are other > functions in django.shortcuts that do (e.g. get_object_or_404), and the > error is triggered on any import of django.db.* > > Carl > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.4 default database required?
On 04/02/2012 09:35 AM, Optimus Paul wrote: > I've been running Django for quite a while without a "database", we > use MongoDB, and it has worked well for us. We upgraded to 1.4 and > found that suddenly a default database is required. Is there a reason > for this? Or is this a bug? Preston has the right solution for this - delete your DATABASES setting entirely. I think it would be best if an empty DATABASES setting had the same effect, especially since that's how it was in 1.3 - if you'd be willing to file a ticket for that, that'd be great. > We get the error when importing django.shortcuts.render_to_response, > which doesn't seem like the kind of place a database connection would > even be required. render_to_response doesn't require a database, but there are other functions in django.shortcuts that do (e.g. get_object_or_404), and the error is triggered on any import of django.db.* Carl signature.asc Description: OpenPGP digital signature
Re: Django 1.4 default database required?
On Monday, April 2, 2012 8:35:28 AM UTC-7, Optimus Paul wrote:
>
> I've been running Django for quite a while without a "database", we
> use MongoDB, and it has worked well for us. We upgraded to 1.4 and
> found that suddenly a default database is required. Is there a reason
> for this? Or is this a bug?
>
> We get the error when importing django.shortcuts.render_to_response,
> which doesn't seem like the kind of place a database connection would
> even be required.
Any chance you have an explicit empty DATABASES={} setting? Try deleting
that setting entirely and see if it works.
As part of the removal of the backwards compatibility shim for the old
DATABASE_* settings, the global settings contains a DATABASES setting that
uses the dummy backend for the default database. This global setting will
silence the import errors, but still raise an error if you try to do
anything that uses the DB.
-Preston
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/bAjgMbeYb-wJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: [GSOC 2012] Customizable serialization
It's my second approach to customizable serialization. I did some
research, find some REST serializers. I focus more on deserialization -
it should be easy to provide data is round-trippable. I discard some
unnecessary fields and try to improve functionality.
GSOC 2012 Customizable serialization
---
Django has a framework for serialization but it is simple tool. The main
problem is impossibility to define own serialization structure and no
support for related models. Below I present a proposal to improve
current framework.
In my opinion it is not possible to create a framework completely
independent of formats that will be user to serialize objects. For
instance XML has richer syntax than json (e.g. fields can be tags or
attributes) so we must provide functions to handle it which won't be
useful in JSON serialization.
---
Features to implement:
---
Based on presented issues to consider, GSOC proposal from last years and
django-developers group threads I prepare a list of features that good
solution should have.
1. Defining the structure of serialized object
1.1. Object fields can be at any position in output tree.
1.2. Renaming fields
1.3. Serializing non-database attributes/properties
1.4. Serializing any subset of object fields.
2. Defining own fields
2.1. Related model fields
2.1.1. Serializing foreign keys, m2m and reverse relations
2.1.2. Choose depth of serialization
2.1.3. Handling natural keys
2.1.4. Handling objects serialized before (in other location of output tree)
2.1.5. Object of same type can be differently handled depends on location
2.2. Other fields - custom serialization (e.g. only date in datetime fields)
3. One definition can support multiple serialization formats (XML, JSON,
YAML).
4. Backward compatible
5. Solution should be simple. Easy to write own serialization scheme.
Below I have tags like (F2.1.2) - means support for feature 2.1.2.
--
Concept:
--
Make the easy things easy, and the hard things possible.
In my proposal I was inspired by Django Forms and django-tastypie.
Tastypie is great API framework for Django.
Output structure will be defined declarative using classes. For sure
there is needed class for model definition. In my solution I define also
model fields with classes. It's the simplest way to provide free output
structure.
There should be two phases of serialization. In first phase Django
objects like Models or Querysets will be write as native Python types
(F3) and then in second phase it will be serialized to chooses format.
Suppose we want to serialize this model:
class Comment(Model):
user = ForeignKey(Profile)
photo = ForeignKey(Photo)
topic = CharField()
content = CharField()
created_at = DateTimeField()
ip_address = IPAddressField()
class User(Model):
fname = CharField()
lname = CharField()
class Photo(Model):
sender = ForeignKey(User)
image = ImageField()
Below we have definition of serializer classes CommentSerializer.
If we want to serialize comment queryset:
serializers.serialize('json|xml|yaml', queryset,
serializer=CommentSerializer, **options)
If 'serializer' isn't provided we have defaults serializer for each
format (F3)
class CommentSerializer(ModelSerializer):
content = ContentField()
topic = TopicField(attribute=True)
photo = ForeignKey(serializer=PhotoSerializer)
y = YField() #(F1.1.3)
def dehydrate__datetime(self, obj): #(F2.2)
return smart_unicode(obj.date())
def hydrate__date(self, obj): #(F2.2)
return smart_unicode(datetime.combine(obj, datetime.time.now()))
class Meta:
aliases = {'topic' : 'subject'}
#fields = (,)
exclude = ('ip_address',)
relation_reserialize = FlatSerializer
field_serializer = FieldSerializer
# subclass of ModelSerializer or FieldSerializer
relation_serializer =
FlatSerializer|ModelSerializer|NaturalModelSerializer|MyModelSerializer
object_name = "my_obj"
model_name = "model"
ModelSerializer has definition of fields, methods and Meta class.
Default each field is serialized by Meta.field_serializer or
Meta.relation_serializer. ModelSerializer fields redefining this
behavior. ModelSerializer methods dehydrate__xxx redefining
serialization for type xxx, and hydrate__xxx is for deserialization.
ModelSerializer methods returns native Python types
I will explain ModelSerializer fields later
Meta Class
a) aliases - redefine field name: topic : "..." => subject : "...". Can
do 'topic' : '' - return of topic method is one level higher. There is
metatag __fields__ - rename all fields. If more than one field has same
name list is created #(F1.2)
b) fields - fields to serialize #(F1.4)
c) exclude - fields to not serialize #(F1.4)
g) relation_reserialize - using what Serializer if object was serialized
before(F2.1.4)
h) field_serializer - default field serializer
h) relation_serializer - default relation (ForeingKey or ManyToMany)
serializer. There are some build-in posibilities: (2.1)
* FlatSerialzer - only primary key - default
* ModelSeria
Django 1.4 default database required?
I've been running Django for quite a while without a "database", we use MongoDB, and it has worked well for us. We upgraded to 1.4 and found that suddenly a default database is required. Is there a reason for this? Or is this a bug? We get the error when importing django.shortcuts.render_to_response, which doesn't seem like the kind of place a database connection would even be required. -- 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: Admin custom function calls
Please ask questions about using Django in django-users. The topic of this list is the development of Django itself. Karen -- 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.
Admin custom function calls
Hi all, I am using Django admin interface for data entry and permissions. I have a requirement like after adding a new row in the table i need to call a function which does something else with the inserted data. Does the admin interface has any option where i can pass something like the callback function which can be called after inserting a data in that model ? Pradeep -- 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.
