Re: auth.user refactor: the profile aproach
django.contrib.auth.get_user already uses BACKEND_SESSION_KEY to decide from which backend to get user object. To support multiple user models, we can just change the AUTHENTICATION_BACKENDS setting to a dict just as DATABASES. AUTHENTICATION_BACKENDS = { 'default': { 'BACKEND': 'django.contrib.auth.backends.ModelBackend', 'MODEL': 'django.contrib.auth.models.User', }, } Instead of a single global USER_MODEL setting, each app should have its own USER_MODEL settings, like ADMIN_USER_MODEL, COMMENTS_USER_MODEL . I do not like `ForeignKey(settings.ADMIN_USER_MODEL or settings.USER_MODEL)` . I prefer a combination of solution 2a and 2b to that. On 4月4日, 上午5时51分, Alex Ogier wrote: > Thanks for the response, Adrian. > > > 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 think convenience methods are nice and all, but we should be careful of > making "The Registered User(tm)" too much of a baked-in concept. Ian Lewis > made a great point a few weeks ago: There are domains in which it is > frankly inappropriate for various authenticated users to mix in the same > database table with the same uniqueness constraints. Maybe you run a > medical record management site, and some of your users are administrative > staff and doctors, and some are patients. Sure, you could manage this by > having a unified model containing everything, and carefully validating with > an "is_doctor" field the way contrib.admin handles "is_admin," but it might > be more appropriate to have separate models. It becomes much easier to > express authorization constraints such as, "As a hospital administrator, > Ms. Sally Johnson is authorized to view the patient list of Dr. John Smith, > but *absolutely not* his record as a patient himself," or "Patients like > Dr. John Smith can be authenticated via Facebook Connect, but doctors need > to be authenticated via our internal LDAP." You can have login ModelForms > for doctors that log in to doctor records and the Django admin site, and > login ModelForms for patients that let them view their own records through > the frontend. > > Obviously supporting multiple user models isn't something that should be a > priority for Django, but locking people out of the choice seems unwise, > when we can get the option "for free": just let authentication backends > return any authenticated object at all to add as request.user. Python's > duck typing will get you the rest of the way, except for those persnickety > tables that absolutely must have a specific concrete table to foreignkey > on. We already do something similar for AnonymousUsers, exposing a common > interface at request.user that isn't backed up by the canonical User table. > Generalizing that is A Good Idea in my opinion. > > Anyways I look forward to seeing how this progresses. I'd love to be a part > of making this happen. Would you like me to turn my work on breaking up > auth.User into reusable chunks into a ticket on trac? I think it makes > sense to merge no matter what we decide on for specific settings and access > mechanisms to developer-defined users. > > 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: Proposal: upgrading the choices machinery for Django
I like this - it solves something that's always bugged me. One nice addition would be to specify explicitly what .id a particular Choice should have. It would be useful in converting existing code that might not have chosen to number its choices the same way this proposal does by default. It looks like you could use Choices.Group(n-1) to make the next choice defined use id=n, but that's not very elegant. -- 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
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. Seems to me that the main benefit of the swappable models approach is just to avoid backwards incompatibility issues by making the change opt-in, but I think it's also opening Pandora's box. I think that leaving it up to developers to ensure that their swapped-in models simply behave enough like the original is going to cause subtle and difficult to trace bugs. App developers won't be able to have confidence that models they have defined will actually be used as defined. This is why I would prefer to simply have an empty `User` model that is basically just a PK, which is used only as the glue that connects all the related bits and pieces (auth models, profile models, group and permissions models, etc.) The rest of the existing `User` fields can be implemented in an `AdminUser` model, and allow multiple authentication backends, which defaults to just an `AdminUserBackend` authentication backend. Apps and projects can just use this if they like, or they can define whatever models they like to link to the user (if they want to hook into other data that is linked to the user), along with their own auth backend. Then users can login with either admin credentials, or your project/apps credentials. A few abstract user base classes or auth backend classes could help make this part easier. I'm not convinced that there should even be this concept (like the "data bag") that an app can rely on "some app" ("any app") defining a value for a user related field (e.g. name, email, twitter name, etc.), without knowing or caring which app has defined it. If you don't know which app defines the data, how can you know that it is the correct data for your app and your purpose? Likewise if you change a value, how do you know it won't inadvertently impact another app that relies on it? You won't know what other apps will be installed along side your own, what fields they will define, or when they will want to overwrite those fields. There is such a thing as too generic. People can and do already define their own user/profile models and authentication backends. They can and do create their own models to store arbitrary data like name, twitter name, longer email address. The only problem is that there are then required and redundant or insufficient vestigial fields left over in `auth.User`. I have my own user model with username field, but I have to fake an `auth.User.username` to connect my user to groups and permissions. I can't use signals to sync my username/email address to `auth.User.email` for the Django admin because it's only 75 characters long and not RFC compliant. If `auth.User` was just a glue model, with just a PK, and the other fields were moved to `AdminUser` (and `AdminUser.email increased in length), this would be a non-issue because I would not need to even have an `AdminUser` at all to create users for my app/project. I would only need to create one for users of the admin app, and in that case I should adhere to the AdminUser model's field requirements. Cheers. Tai. On Wednesday, 4 April 2012 15:25:40 UTC+10, Eric Florenzano wrote: > > I completely agree with Adrian's proposal, with these amendments suggested > by Russell in order to build something slightly more generic, like > LazyForeignKey, instead of UserField. In fact, a UserField coud end up > being provided as a subclass of LazyForeignKey with a default name provided > (e.g. 'user') and any other user-domain-specific customizations needed. > > Thanks, > Eric Florenzano > >> -- 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/-/gMdsJCSMmKIJ. 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: Proposal: upgrading the choices machinery for Django
Wiadomość napisana przez Dan Poirier w dniu 4 kwi 2012, o godz. 14:08: > One nice addition would be to specify explicitly what .id a particular > Choice should have. It would be useful in converting existing code that > might not have chosen to number its choices the same way this proposal > does by default. It looks like you could use Choices.Group(n-1) to make > the next choice defined use id=n, but that's not very elegant. Right. The ability to explicitly set the .id on a single choice is useful. The only reason it's not already there is that I didn't want to write my own `makemessages`. Then again I might do just that. My proposal is based on a working implementation because I didn't want to fall into bikeshedding on what could have been theoretically implemented. What we need now to push things forward is a list of +1, +1 if ..., +0, +0 if ..., -1, "how dare you?!" from a bunch of people. -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. http://lukasz.langa.pl/ +48 791 080 144 -- 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
Regarding swappable models: In general, good reusable applications allow developers to substitute in their own class or subclass for the module author's default by either a custom setting or an argument to a method. In general, there's no reason why that mechanism is insufficient, and should be done per application. Right now, we're trying to solve the swappable model *for User*, which is a bigger problem because it's not confined to a single app; it's defined in auth, but auth functions as a nexus for lots of other things. Regards, Luke -- 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: Proposal: upgrading the choices machinery for Django
Am 03.04.2012 21:31, schrieb Łukasz Langa: A nice HTML rendering of this proposal is available at: http://lukasz.langa.pl/2/upgrading-choices-machinery-django/ == Upgrading the choices machinery for Django == ... since most people have something like this in their code, a better solution should require only some additional characters. GENDER_CHOICES = ( (0, 'male'), (1, 'female'), (2, 'not specified'), ) # if this would be supported, updating the code would be easy GENDER_CHOICES = Choices( (0, 'male'), (1, 'female'), (2, 'not specified'), ) #about Group >>> class License(Choices): ... COPYLEFT = Choices.Group(0) ... gpl_any = Choice("GPL, any") I don't like Choices.Group. I think it is better if choices must be set explicit, not implicit (auto-increment). Here is my solution, which is similar to way3 in your proposal. {{{ class ChoiceDict(SortedDict): ''' Iterating this SortedDict will return the items (and not the keys). This is handy if you want to uses this for a choice list on a model field ''' __iter__=SortedDict.iteritems class Foo(models.Model): STATE_NEW='new' STATE_DONE='done' states=ChoiceDict((STATE_NEW, _('new')), (STATE_DONE, _('done')), ) state=models.CharField(max_length=16, verbose_name=u'Status', default=STATE_NEU, choices=states) }}} I like this since, you can access the verbose string like this: Foo.states[obj.state] -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- 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 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.
Re: auth.user refactor: the profile aproach
On Wednesday, April 4, 2012 at 9:44 AM, Russell Keith-Magee wrote: > 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. As the original author and designer of that pattern, I should probably point out that I now think it's a mistake. Have you actually tried using it? It doesn't really work very well. Every time I've introduced any sort of "swappable model" mechanism I've come to regret it. I'm -1 on the idea of generalized "swappable model" mechanism. I can stomach it for User because in this context it's not any worse than the alternatives, but as a generalized mechanism it makes me really, really unhappy. Decoupling is a laudable goal, but providing a mechanism to reach in and effect code not under your control isn't good design. We use derisive terms like "monkeypatching" for a reason. I'm sure there are good reasons for wanting swappable models. Russ, I know you're smarter than me, so the fact that you want LazyForeignKey so much probably indicates that you've got some really solid use cases in mind. But really this is a hard veto from me; I just can't be convinced that this sort of mechanism is anything but bad news. However, I don't see why we should actively prevent this sort of thing being done externally, so if there's anything in Django that's precluding the creation of a LazyForeignKey as an external add-on let's consider that limitation a bug and get it fixed. 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: [GSoC 2012] Enhanced contrib.auth
Hello, I'm apologizing for replying to my own post, but there are only two days left before GSoC's submission deadline and my proposal has received very little feedback. Since other proposals about contrib.auth are being discussed, I was wondering if mine has any merit and whether I should submit it through google-melange. Thanks. -- 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/-/eVNJcUUEJ1wJ. 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: Proposal: upgrading the choices machinery for Django
Wiadomość napisana przez Thomas Guettler w dniu 4 kwi 2012, o godz. 15:55: > since most people have something like this in their code, a better solution > should require > only some additional characters. Thank you for your feedback. I disagree since it wouldn't address any of the original concerns from the proposal. Most importantly, reducing redundancy and creating a canonical place for storing information of a specific concept. > I think it is better if choices must be set explicit, not > implicit (auto-increment). As Dan Poirier pointed out, setting an explicit .id on a single Choice will let you do that. > Here is my solution, which is similar to way3 in your proposal. Doesn't support groups, uses the tuple-galore syntax, still leaves you with redundancy of having to first define available options and later building a choice dictionary. -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. http://lukasz.langa.pl/ +48 791 080 144 -- 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
Hi Russell, Thanks for your immense patience :-) These are some additions to my proposal above, based on your inputs: Status of current 'creation' code in django: The current code, for e.g. sql_create_model in django.db.backends.creation is a mix of *inspection* part and *sql generation* part. Since the sql generation part will (should) now be handled by our new CRUD API, I will refactor django.db.backends.creation (and other backends' creation modules) to continue using their inspection part but using our new CRUD API for sql generation. The approach will be to get the fields using model._meta.local_fields and feeding them to our new CRUD API. This will serve to be a proof of concept for my API. As for testing using Django code, my models will be something like: class UnchangedModel(models.Model): eg = models.TextField() if BEFORE_MIGRATION: class MyModel(models.Model): f1 = models.TextField() f2 = models.TextField() # Deletion of a field else: class MyModel(models.Model): f1 = models.TextField() The value of BEFORE_MIGRATION will be controlled by the testing code. A temporary environment variable can be used for this purpose. Also a revised schedule: Bonding period before GSoC: Discussion on API design Week 1: Writing tests (using 2 part checks (checking the actual database and using Django models), as discussed above) Week 2: Developing the base migration API Week 3: Developing extensions and overrides for PostgreSQL Weeks 4-5 : Developing extensions and overrides for MySQL Weeks 6-7 : Developing extensions and overrides for SQLite (may be shorter or longer (by 0.5 week) depending on how much of xtrqt's code is considered acceptable) Weeks 8-10 : Refactoring django.db backends.creation (and the PostgreSQL, MySQL, SQLite creation modules) to use the new API for SQL generation (approach discussed above) Week 11 : Writing documentaion and leftover tests, if any Week 12 : Buffer week for the unexpected On Tuesday, 3 April 2012 06:39:37 UTC+5:30, Russell Keith-Magee wrote: > > > 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 pro
Re: Proposal: upgrading the choices machinery for Django
Hi Lukash, I'm 0 to this. I find it well thought out but in my use cases I fail to see the advantage over the WAY 3 (or WAY 4 pointed out below) and it adds a layer of abstraction where a straight tuple or a list does the job well enough. The choice filtering could come in handy and in the end I don't see why this can't co-exist with django's standard way. WAY 4: class UserManager(models.Manager): GENDER_MALE = 0 GENDER_FEMALE = 1 GENDER_NOT_SPECIFIED = 2 GENDER_CHOICES = ( (GENDER_MALE, _('male')), (GENDER_FEMALE, _('female')), (GENDER_NOT_SPECIFIED, _('not specified')), ) def males(self): """ Returns all entries accessible through front end site""" return self.all().filter(gender=self.GENDER_MALE) def females(self): """ Returns all entries accessible through front end site""" return self.all().filter(gender=self.GENDER_FEMALE) ... class User(models.Model): gender = models.IntegerField(choices=UserManager.GENDER_CHOICES, default=UserManager.GENDER_NOT_SPECIFIED) objects = UserManager() ef greet(self): if self.gender == UserManager.GENDER_MALE: return 'Hi, boy.' elif self.gender == UserManager.GENDER_NOT_SPECIFIED: return 'Hello, girl.' else: return 'Hey there, user!' -Original Message- From: Łukasz Langa Sent: Wednesday, April 04, 2012 9:15 AM To: django-developers@googlegroups.com Subject: Re: Proposal: upgrading the choices machinery for Django Wiadomość napisana przez Dan Poirier w dniu 4 kwi 2012, o godz. 14:08: One nice addition would be to specify explicitly what .id a particular Choice should have. It would be useful in converting existing code that might not have chosen to number its choices the same way this proposal does by default. It looks like you could use Choices.Group(n-1) to make the next choice defined use id=n, but that's not very elegant. Right. The ability to explicitly set the .id on a single choice is useful. The only reason it's not already there is that I didn't want to write my own `makemessages`. Then again I might do just that. My proposal is based on a working implementation because I didn't want to fall into bikeshedding on what could have been theoretically implemented. What we need now to push things forward is a list of +1, +1 if ..., +0, +0 if ..., -1, "how dare you?!" from a bunch of people. -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. http://lukasz.langa.pl/ +48 791 080 144 -- 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
On Wed, Apr 4, 2012 at 9:57 AM, Jacob Kaplan-Moss wrote: > On Wednesday, April 4, 2012 at 9:44 AM, Russell Keith-Magee wrote: > > 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. > > As the original author and designer of that pattern, I should probably point > out that I now think it's a mistake. Have you actually tried using it? It > doesn't really work very well. Every time I've introduced any sort of > "swappable model" mechanism I've come to regret it. Totally agree with Jacob here, plus Tai's comment that "There is such a thing as too generic." We've made the mistake of making things too generic in the past, and it's kind of infuriating in retrospect, both philosophically and in terms of code maintenance/understanding. (django/utils/tree.py, anyone??) I think our policy should be: make the simplest thing that can possibly work for a narrowly-tailored use case, then make things more generic *slowly* if there's a demand. No need to be an Architecture Astronaut. Adrian -- 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 Wednesday, April 4, 2012 at 12:20 PM, Adrian Holovaty wrote: > On Wed, Apr 4, 2012 at 9:57 AM, Jacob Kaplan-Moss (mailto:ja...@jacobian.org)> wrote: > > On Wednesday, April 4, 2012 at 9:44 AM, Russell Keith-Magee wrote: > > > > 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. > > > > As the original author and designer of that pattern, I should probably point > > out that I now think it's a mistake. Have you actually tried using it? It > > doesn't really work very well. Every time I've introduced any sort of > > "swappable model" mechanism I've come to regret it. > > > > > Totally agree with Jacob here, plus Tai's comment that "There is such > a thing as too generic." We've made the mistake of making things too > generic in the past, and it's kind of infuriating in retrospect, both > philosophically and in terms of code maintenance/understanding. > (django/utils/tree.py, anyone??) > > I think our policy should be: make the simplest thing that can > possibly work for a narrowly-tailored use case, then make things more > generic *slowly* if there's a demand. No need to be an Architecture > Astronaut. > > Not adding anything, just saying that Architecture Astronaut is the best term ever for this. > > Adrian > > -- > 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: [GSoC 2012] Enhanced contrib.auth
On Wed, Apr 4, 2012 at 10:16 AM, Stratos Moros wrote: > I'm apologizing for replying to my own post, but there are only two days > left before GSoC's submission deadline and my proposal has received very > little feedback. > > Since other proposals about contrib.auth are being discussed, I was > wondering if mine has any merit and whether I should submit it through > google-melange. Hi Stratos, The core team is going to take the lead on the auth.User refactoring -- specifically, yours truly. :-) Given that the Summer of Code policy prohibits code contributions from non-students (right?), I don't think the User refactoring would work as a Summer of Code project. Sorry to break this news, as you've clearly done a lot of preparation and thinking about the issue, but of course we'd love to have you contribute to this particular feature *outside* the Summer of Code. Adrian -- 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 Wed, Apr 4, 2012 at 11:22 AM, Donald Stufft wrote: > Not adding anything, just saying that Architecture Astronaut is the best > term ever for this. Here's the source of that term: http://www.joelonsoftware.com/articles/fog18.html http://www.codinghorror.com/blog/2004/12/it-came-from-planet-architecture.html Adrian -- 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: Proposal: upgrading the choices machinery for Django
2012/4/3 Łukasz Langa : > A nice HTML rendering of this proposal is available at: > http://lukasz.langa.pl/2/upgrading-choices-machinery-django/ Disclaimer: all my code currently looks like 'Way 3'. In general, I like it. There are a few things I don't like in it: The class definition grates. When we say things like: class Gender(Choices): male = Choice("male") That says to me that Gender.male is mutable. Ick. There is no easy way by inspecting the code to see what choice a value of 7 equates to any-more. Do the choices start from 0 or do they start from 1, as inferred by the examples (Why? What is wrong with 0?). Repetition isn't good, but ambiguity is worse. I don't like the grouping at all. Grouping under the old system was clean and simple, it didn't require magic arguments, groups didn't require that all options are contiguous in a single range. This grouping system just seems destined for data loss/confusion. If I want to split a group in two, the enums in the new group change values! That is not a good approach, and was not necessary with the old system. This grouping system cannot logically arrange the options into groups, since it relies on them being attributes of the class, and so you need to invent a way of grouping. If I had a vote, I'd be strongly -1 on any proposal with this sort of grouping, it seems dangerous and wrong. Finally, the proposal seems to concentrate solely on choices as an enum. The proposal completely ignores that choices can be almost any kind of value, eg: MALE="m" FEMALE="f" UNKNOWN="?" GENDER_CHOICES = ( (MALE, "Male"), (FEMALE, "Female"), (UNKNOWN, "Unknown"), ) this would be an entirely appropriate choices for a CharField. Cheers Tom -- 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: Proposal: upgrading the choices machinery for Django
2012/4/3 Łukasz Langa : > Explicit choice values:: > > GENDER_MALE = 0 > GENDER_FEMALE = 1 > GENDER_NOT_SPECIFIED = 2 > > GENDER_CHOICES = ( > (GENDER_MALE, _('male')), > (GENDER_FEMALE, _('female')), > (GENDER_NOT_SPECIFIED, _('not specified')), > ) > > class User(models.Model): > gender = models.IntegerField(choices=GENDER_CHOICES, > default=GENDER_NOT_SPECIFIED) > > def greet(self): > if self.gender == GENDER_MALE: > return 'Hi, boy.' > elif self.gender == GENDER_NOT_SPECIFIED: > return 'Hello, girl.' > else: return 'Hey there, user!' > > This is a saner way but starts getting overly verbose and redundant. You can > improve encapsulation by moving the choices into the ``User`` class but that > on > the other hand beats reusability. I don't see the immediate need for Yet Another Sub-framework, as described in this proposal. This is what I normally do, and it works fine: class User(models.Model): MALE = 0 FEMALE = 1 GENDERS = [(MALE, 'Male'), (FEMALE, 'Female')] gender = models.IntegerField(choices=GENDERS) def greet(self): return {MALE: 'Hi, boy', FEMALE: 'Hi, girl.'}[self.gender] If people aren't understanding that, we should improve our documentation. Also, the fact that we *don't* have a sub-framework for this lets people do whatever they want -- including using the dj.choices module. So I am -1 on including this in Django proper. Adrian -- 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: Proposal: upgrading the choices machinery for Django
I agree we don't really gain anything from including this in core. Django model utils[1] has a pretty solid implementation of a choice abstraction. [1] https://github.com/carljm/django-model-utils On Wed, Apr 4, 2012 at 11:41 AM, Adrian Holovaty wrote: > 2012/4/3 Łukasz Langa : >> Explicit choice values:: >> >> GENDER_MALE = 0 >> GENDER_FEMALE = 1 >> GENDER_NOT_SPECIFIED = 2 >> >> GENDER_CHOICES = ( >> (GENDER_MALE, _('male')), >> (GENDER_FEMALE, _('female')), >> (GENDER_NOT_SPECIFIED, _('not specified')), >> ) >> >> class User(models.Model): >> gender = models.IntegerField(choices=GENDER_CHOICES, >> default=GENDER_NOT_SPECIFIED) >> >> def greet(self): >> if self.gender == GENDER_MALE: >> return 'Hi, boy.' >> elif self.gender == GENDER_NOT_SPECIFIED: >> return 'Hello, girl.' >> else: return 'Hey there, user!' >> >> This is a saner way but starts getting overly verbose and redundant. You can >> improve encapsulation by moving the choices into the ``User`` class but that >> on >> the other hand beats reusability. > > I don't see the immediate need for Yet Another Sub-framework, as > described in this proposal. This is what I normally do, and it works > fine: > > class User(models.Model): > MALE = 0 > FEMALE = 1 > GENDERS = [(MALE, 'Male'), (FEMALE, 'Female')] > gender = models.IntegerField(choices=GENDERS) > > def greet(self): > return {MALE: 'Hi, boy', FEMALE: 'Hi, girl.'}[self.gender] > > If people aren't understanding that, we should improve our documentation. > > Also, the fact that we *don't* have a sub-framework for this lets > people do whatever they want -- including using the dj.choices module. > So I am -1 on including this in Django proper. > > Adrian > > -- > 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: Proposal: upgrading the choices machinery for Django
Wiadomość napisana przez Daniel Sokolowski w dniu 4 kwi 2012, o godz. 17:52: > The choice filtering could come in handy and in the end I don't see why this > can't co-exist with django's standard way. > > WAY 4: Nice but very verbose. -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. http://lukasz.langa.pl/ +48 791 080 144 -- 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: Proposal: upgrading the choices machinery for Django
Wiadomość napisana przez Tom Evans w dniu 4 kwi 2012, o godz. 18:40: > The class definition grates. When we say things like: > > class Gender(Choices): >male = Choice("male") > > That says to me that Gender.male is mutable. Ick. Thanks for your feedback. Do model and form field definitions say that as well? It's true that I could have block users from mutating the value but "we're all consenting adults here", right? > There is no easy way by inspecting the code to see what choice a value > of 7 equates to any-more. True, the same goes for spotting errors with manual numbering when there are many values. > Do the choices start from 0 or do they start > from 1, as inferred by the examples (Why? What is wrong with 0?). > Repetition isn't good, but ambiguity is worse. It's a matter of aesthetics and as such it's totally subjective. I made the values start from 1 so that the first Choice.Group can have value 0 and not -1 which looks ugly. > This grouping system just seems destined for data loss/confusion. If I > want to split a group in two, the enums in the new group change > values! That is not a good approach, and was not necessary with the > old system. I can't see how they have to. > If I had a vote, I'd be strongly -1 on > any proposal with this sort of grouping, it seems dangerous and wrong. Can you elaborate on what is dangerous about them? > Finally, the proposal seems to concentrate solely on choices as an > enum. The proposal completely ignores that choices can be almost any > kind of value, eg: > > MALE="m" > FEMALE="f" > UNKNOWN="?" > GENDER_CHOICES = ( >(MALE, "Male"), >(FEMALE, "Female"), >(UNKNOWN, "Unknown"), > ) > > this would be an entirely appropriate choices for a CharField. Using code in my proposal: >>> class Gender(Choices): ... m = Choice("male") ... f = Choice("female") ... n = Choice("not specified") ... >>> Gender(item=lambda c: (c.name, c.desc)) [(u'm', u'male'), (u'f', u'female'), (u'n', u'not specified')] -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. http://lukasz.langa.pl/ +48 791 080 144 -- 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: Proposal: upgrading the choices machinery for Django
Wiadomość napisana przez Adrian Holovaty w dniu 4 kwi 2012, o godz. 18:41: > Also, the fact that we *don't* have a sub-framework for this lets > people do whatever they want -- including using the dj.choices module. > So I am -1 on including this in Django proper. Thank you for your feedback. As you're one of the BFDLs for the project, that basically closes the proposal as rejected, am I right? -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. http://lukasz.langa.pl/ +48 791 080 144 -- 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] Enhanced contrib.auth
On Wed, 04 Apr 2012 19:25:26 +0300, Adrian Holovaty wrote: Hi Stratos, The core team is going to take the lead on the auth.User refactoring -- specifically, yours truly. :-) Given that the Summer of Code policy prohibits code contributions from non-students (right?), I don't think the User refactoring would work as a Summer of Code project. Sorry to break this news, as you've clearly done a lot of preparation and thinking about the issue, but of course we'd love to have you contribute to this particular feature *outside* the Summer of Code. Adrian Ok. I'd love to contribute either way. Thanks for the info. -- 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.
[GSoC 2012] auth.User replacement proposal
Hi folks, I've decided to go ahead and make a GSoC proposal out of the discussion around auth.User replacement. I'd love to contribute to this and carry through my ideas to their conclusion, even if this proposal is shot down. The proposal in full is at https://gist.github.com/2304321. I will continue to keep that up to date as long as the proposal has breath left in it. To Adrian specifically: You have indicated on this list that you are eager to have at this problem yourself, and that may make this proposal a non-starter. I think we are very much on the same page in terms of technical direction and end goals of the refactoring: I want to make this change as conservative as possible from a technical standpoint, but document, test and validate it as much as possible from the community's standpoint. I think we have strong motivation for the specific decisions we agreed on, and they give the project enough direction that it will rapidly become obvious if and when I am derailing your conception of what needs to be done, so I hope you will consider letting it be done as a GSoC project. 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: [GSoC 2012] auth.User replacement proposal
On Wednesday, April 4, 2012 at 1:16 PM, Alex Ogier wrote: > To Adrian specifically: You have indicated on this list that you are eager to > have at this problem yourself, and that may make this proposal a non-starter. > I think we are very much on the same page in terms of technical direction and > end goals of the refactoring: I want to make this change as conservative as > possible from a technical standpoint, but document, test and validate it as > much as possible from the community's standpoint. I think we have strong > motivation for the specific decisions we agreed on, and they give the project > enough direction that it will rapidly become obvious if and when I am > derailing your conception of what needs to be done, so I hope you will > consider letting it be done as a GSoC project. > > > The issue is specifically that GSoC does not allow collaboration -- all the code needs to be written by the student. There's a lot of people, including Adrian, who want to contribute; doing this as a GSoC project would actively prevent them from contributing. Auth refactoring really can't be a GSoC project, sorry. If you really want to work on auth, you'll need to do it outside of GSoC. If it's an issue of money making the difference between being able to work on the project and not, then let me know. We can perhaps look at taking the costs until the DSF's wing instead of GSoC, and thus not get into the way of Google's rules. 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: auth.user refactor: the profile aproach
I agree with Luke that more explicit is better then implicit when dealing with the user.data. From: Luke Sneeringer Sent: Tuesday, April 03, 2012 2:46 PM To: django-developers@googlegroups.com Subject: Re: auth.user refactor: the profile aproach So, after reading this, I think I really only have a couple questions/concerns: 1. What, if anything, is the primary key on the base User model? Is it the identifier? If so, can it be specified as the primary key, rather than unique=True, db_index=True? If it's not the primary key, is it the usual magical id = models.AutoField()? 2. I'm a little nervous about the magical installation of Profile modules -- specifically, what happens once this system has been around for one to two years and we have a ton of these? I'm imagining a situation where there are lots of apps floating around, each with their own Profile subclasses that install behind the scenes when you install the app (and which you may or may not actually realize up front -- yes, a good developer *should* be aware of that, but that doesn't mean they will be...). What happens if a beginner writes everything against user.data['name'], and then installs an app that adds a new name, which is unordered and magically ends up on top, and therefore introduces new, unexpected, and, most importantly, extremely difficult to debug logic errors? I agree with some of the criticisms of swappable user models, but at least the developer always knows what he is doing in that case. In this case, the behavior of your user model can change in unexpected ways when you do something that seems totally unrelated; some code that previously worked might either (1) return different data or (2) suddenly raise KeyError. Perhaps this is the best of bad options. I agree there's a decent bit to be argued in favor of it, but can we figure out a less error-prone way for user.data to work? Honestly, I think it would be less risky to force everyone to write user.admin_profile.name -- it's more typing, but at least it's explicit. The current proposal for user.data doesn't actually pass "refuse the temptation to guess", because it glosses over the fact that developers *will guess* and then their code will stop working after what feels like a completely unrelated change. 3. Might I suggest that the Profile model that the admin requires be called AdminProfile and not DefaultProfile? It's really an admin need more than anything else. Best Regard, Luke On April 2, 2012, at 19:35 , 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. 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. -- 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
Re: auth.user refactor: the profile aproach
I made this in response to Jacob's original proposal, which I understand to have been scrapped in favor of Adrian's (which doesn't have user.data at all, thankfully). Therefore, I believe my point below is now moot. For the record, I am much more excited about Adrian's proposal (no offense, Jacob :)). I was convinced that profiles was the only way to go when I read Jacob's proposal, but it sounds like there is a mechanism to make swappable User models work, which is much more in tune with how I use Django. Profiles, to me, are ugly. At best. Regards, Luke On April 4, 2012, at 15:28 , Daniel Sokolowski wrote: > I agree with Luke that more explicit is better then implicit when dealing > with the user.data. > > From: Luke Sneeringer > Sent: Tuesday, April 03, 2012 2:46 PM > To: django-developers@googlegroups.com > Subject: Re: auth.user refactor: the profile aproach > > So, after reading this, I think I really only have a couple > questions/concerns: > > 1. What, if anything, is the primary key on the base User model? Is it the > identifier? If so, can it be specified as the primary key, rather than > unique=True, db_index=True? If it's not the primary key, is it the usual > magical id = models.AutoField()? > > 2. I'm a little nervous about the magical installation of Profile modules -- > specifically, what happens once this system has been around for one to two > years and we have a ton of these? I'm imagining a situation where there are > lots of apps floating around, each with their own Profile subclasses that > install behind the scenes when you install the app (and which you may or may > not actually realize up front -- yes, a good developer *should* be aware of > that, but that doesn't mean they will be...). What happens if a beginner > writes everything against user.data['name'], and then installs an app that > adds a new name, which is unordered and magically ends up on top, and > therefore introduces new, unexpected, and, most importantly, extremely > difficult to debug logic errors? > > I agree with some of the criticisms of swappable user models, but at least > the developer always knows what he is doing in that case. In this case, the > behavior of your user model can change in unexpected ways when you do > something that seems totally unrelated; some code that previously worked > might either (1) return different data or (2) suddenly raise KeyError. > > Perhaps this is the best of bad options. I agree there's a decent bit to be > argued in favor of it, but can we figure out a less error-prone way for > user.data to work? Honestly, I think it would be less risky to force everyone > to write user.admin_profile.name -- it's more typing, but at least it's > explicit. The current proposal for user.data doesn't actually pass "refuse > the temptation to guess", because it glosses over the fact that developers > *will guess* and then their code will stop working after what feels like a > completely unrelated change. > > 3. Might I suggest that the Profile model that the admin requires be called > AdminProfile and not DefaultProfile? It's really an admin need more than > anything else. > > > Best Regard, > Luke -- 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: Proposal: upgrading the choices machinery for Django
On Wednesday, April 4, 2012 9:41:23 AM UTC-7, Adrian Holovaty wrote: > 2012/4/3 Łukasz Langa : > > Explicit choice values:: > > > > GENDER_MALE = 0 > > GENDER_FEMALE = 1 > > GENDER_NOT_SPECIFIED = 2 > > > > GENDER_CHOICES = ( > > (GENDER_MALE, _('male')), > > (GENDER_FEMALE, _('female')), > > (GENDER_NOT_SPECIFIED, _('not specified')), > > ) > > > > class User(models.Model): > > gender = models.IntegerField(choices=GENDER_CHOICES, > > default=GENDER_NOT_SPECIFIED) > > > > def greet(self): > > if self.gender == GENDER_MALE: > > return 'Hi, boy.' > > elif self.gender == GENDER_NOT_SPECIFIED: > > return 'Hello, girl.' > > else: return 'Hey there, user!' > > > > This is a saner way but starts getting overly verbose and redundant. You > can > > improve encapsulation by moving the choices into the ``User`` class but > that on > > the other hand beats reusability. > > I don't see the immediate need for Yet Another Sub-framework, as > described in this proposal. This is what I normally do, and it works > fine: > > class User(models.Model): > MALE = 0 > FEMALE = 1 > GENDERS = [(MALE, 'Male'), (FEMALE, 'Female')] > gender = models.IntegerField(choices=GENDERS) > > def greet(self): > return {MALE: 'Hi, boy', FEMALE: 'Hi, girl.'}[self.gender] > > If people aren't understanding that, we should improve our documentation. > > Also, the fact that we *don't* have a sub-framework for this lets > people do whatever they want -- including using the dj.choices module. > So I am -1 on including this in Django proper. > > Adrian > +1 to what Adrian says. In fact... On two occasions now I've had to do serious debugging on implementations done by other people who used a technique not dissimilar to what Łukasz proposes. In both cases, while the inheritance and better control structures were nice, the issue was that if you give people enough rope to hang themselves, they will. The current system works very well, especially when you follow Adrian's pattern. Lukasz' system works well too. Therefore... I submit that we keep Django core for choices as is and let people who want to use another system implement 3rd party packages. -- 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/-/F20PJZowsZ4J. 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: Proposal: upgrading the choices machinery for Django
Wiadomość napisana przez Daniel Greenfeld w dniu 4 kwi 2012, o godz. 22:48: > +1 to what Adrian says. Thanks for your input! :) > On two occasions now I've had to do serious debugging on implementations done > by other people who used a technique not dissimilar to what Łukasz proposes. > In both cases, while the inheritance and better control structures were nice, > the issue was that if you give people enough rope to hang themselves, they > will. Can you elaborate on that a bit? Even if the proposal is rejected in the end, I might use your experience to at least make the rope less deadly. -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. http://lukasz.langa.pl/ +48 791 080 144 -- 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 04/04/2012, at 11:50 PM, j4nu5 wrote: > Hi Russell, > Thanks for your immense patience :-) > > These are some additions to my proposal above, based on your inputs: > Status of current 'creation' code in django: > The current code, for e.g. sql_create_model in > django.db.backends.creation is a mix of *inspection* part and *sql > generation* part. Since the sql generation part will (should) now be > handled by our new CRUD API, I will refactor > django.db.backends.creation (and other backends' creation modules) to > continue using their inspection part but using our new CRUD API for > sql generation. The approach will be to get the fields using > model._meta.local_fields and feeding them to our new CRUD API. This > will serve to be a proof of concept for my API. Hrm - not exactly ideal, but better than nothing I suppose. Ideally, there would actually be some migration task involved in your proof of concept. > As for testing using Django code, my models will be something like: > class UnchangedModel(models.Model): >eg = models.TextField() > > if BEFORE_MIGRATION: >class MyModel(models.Model): >f1 = models.TextField() >f2 = models.TextField() > # Deletion of a field > else: >class MyModel(models.Model): >f1 = models.TextField() > > The value of BEFORE_MIGRATION will be controlled by the testing code. > A temporary environment variable can be used for this purpose. Unless your plan also includes writing a lot of extra code to purge and repopulate the app cache, this approach won't work. Just changing a setting doesn't change the class that has already been parsed and processed. > Also a revised schedule: > Bonding period before GSoC: Discussion on API design > Week 1: Writing tests (using 2 part checks (checking the actual > database and using Django models), as discussed above) > Week 2: Developing the base migration API > Week 3: Developing extensions and overrides for PostgreSQL > Weeks 4-5 : Developing extensions and overrides for MySQL > Weeks 6-7 : Developing extensions and overrides for SQLite (may be shorter or > longer (by 0.5 week) depending on how much of xtrqt's code > is > considered acceptable) > Weeks 8-10 : Refactoring django.db backends.creation (and the PostgreSQL, > MySQL, SQLite creation modules) to use the new API for > SQL generation (approach discussed above) > Week 11 : Writing documentaion and leftover tests, if any > Week 12 : Buffer week for the unexpected > This looks a bit more convincing. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: [GSoC 2012] auth.User replacement proposal
Fair enough. My goal was never to shut down collaboration, and if GSoC will do that then I am happy to drop it. The money was never my motivation, and I will definitely still contribute what I can. Best, Alex Ogier On Wed, Apr 4, 2012 at 2:46 PM, Jacob Kaplan-Moss wrote: > On Wednesday, April 4, 2012 at 1:16 PM, Alex Ogier wrote: > > To Adrian specifically: You have indicated on this list that you are eager > to have at this problem yourself, and that may make this proposal a > non-starter. I think we are very much on the same page in terms of > technical direction and end goals of the refactoring: I want to make this > change as conservative as possible from a technical standpoint, but > document, test and validate it as much as possible from the community's > standpoint. I think we have strong motivation for the specific decisions we > agreed on, and they give the project enough direction that it will rapidly > become obvious if and when I am derailing your conception of what needs to > be done, so I hope you will consider letting it be done as a GSoC project. > > > The issue is specifically that GSoC does not allow collaboration -- all > the code needs to be written by the student. There's a lot of people, > including Adrian, who want to contribute; doing this as a GSoC project > would actively prevent them from contributing. Auth refactoring really > can't be a GSoC project, sorry. > > If you really want to work on auth, you'll need to do it outside of GSoC. > If it's an issue of money making the difference between being able to work > on the project and not, then let me know. We can perhaps look at taking the > costs until the DSF's wing instead of GSoC, and thus not get into the way > of Google's rules. > > 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. > -- 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 04/04/2012, at 10:57 PM, Jacob Kaplan-Moss wrote: > On Wednesday, April 4, 2012 at 9:44 AM, Russell Keith-Magee wrote: >> 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. > As the original author and designer of that pattern, I should probably point > out that I now think it's a mistake. Have you actually tried using it? It > doesn't really work very well. Every time I've introduced any sort of > "swappable model" mechanism I've come to regret it. > > I'm -1 on the idea of generalized "swappable model" mechanism. I can stomach > it for User because in this context it's not any worse than the alternatives, > but as a generalized mechanism it makes me really, really unhappy. Decoupling > is a laudable goal, but providing a mechanism to reach in and effect code not > under your control isn't good design. We use derisive terms like > "monkeypatching" for a reason. Agreed that monkeypatching is bad. However, I think that's the wrong analogy in this case; I think "interface" is a closer match. An interface is essentially just a way of saying "I need to operate on an object with these properties, but I'm going to let the end user define the specific object instance that provides those properties". As a language, Python generally doesn't need interfaces because of duck typing. However, ForeignKey is a "strongly typed" database relationship, so you can't duck type it -- the original app developer needs to be able to define it as something that the end developer might want to change. > I'm sure there are good reasons for wanting swappable models. Russ, I know > you're smarter than me, Don't put too much weight in that argument. I have plenty of braindead ideas. The PhD just means I'm persistent :-) > so the fact that you want LazyForeignKey so much probably indicates that > you've got some really solid use cases in mind. But really this is a hard > veto from me; I just can't be convinced that this sort of mechanism is > anything but bad news. To tell the truth, I haven't used the comments app extensively, so I can't really comment on that example specifically. I also don't have a specific case in mind where I want to use this feature. However, if you think of the problem being solved here as interfaces, it isn't hard to think of other possible applications. More broadly, my reaction comes from the the fact that I *have* been bitten -- many times -- by claims that "this is a special case". Special cases almost never are, and the counterexample usually shows up a week after you're irretrievably committed to a "specialized" solution. > However, I don't see why we should actively prevent this sort of thing being > done externally, so if there's anything in Django that's precluding the > creation of a LazyForeignKey as an external add-on let's consider that > limitation a bug and get it fixed. Sure -- I can live with that. There's really only two places where I see this being an issue in practice: 1) Introducing UserField(). I'd be against introducing UserField() as a special case of ForeignKey(). Even though it's more typing, ForeignKey(settings.USER_MODEL) offends me less. This doesn't preclude other developers writing their own ForeignKey shortcuts; I just think it sets a bad example. 2) The synchronization/app cache problem. In order to do this properly, we need to prevent the auth_user table from being created, and auth.User being added to the app cache. If we're going to address this by adding hooks into the model startup process, I'd like to see them as general hooks, rather than special cases for auth.User -- even if they're undocumented hooks. Of course, the other option is just an if statement in the models.py file: if settings.USER_MODEL == 'auth.User': class User(models.Model): username = ... which is a pattern that other uses could adopt. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: upgrading the choices machinery for Django
On Wed, Apr 4, 2012 at 5:18 PM, Łukasz Langa wrote: > Wiadomość napisana przez Daniel Greenfeld w dniu 4 kwi 2012, o godz. 22:48: > > > On two occasions now I've had to do serious debugging on implementations > done by other people who used a technique not dissimilar to what Łukasz > proposes. In both cases, while the inheritance and better control > structures were nice, the issue was that if you give people enough rope to > hang themselves, they will. > > Can you elaborate on that a bit? Even if the proposal is rejected in the > end, I might use your experience to at least make the rope less deadly. I imagine a big one is that without an explicit database representation for every item, it is easy to get out of sync with the real data you have. And when that happens, there isn't necessarily a good way of retrieving the meaning of old data: if some data in your database says that you are using license '302' but that index was implicitly auto-generated by the particular ordering of Choice() instantiations, then when the ordering changes you can lose track (and indexing based on an implicit ordering of class attributes definitely seems shaky to me). When I use enumerated fields, I generally make them VARCHAR(10) or so, and then use plain English, potentially abbreviated, for a database representation. That makes for reasonable code, "if self.license == 'gpl_any':" looks very readable to me, and doesn't restrict you from altering display values for internationalization. It seems to me like this is really a documentation problem, where distilling the wisdom of developers like Adrian into a little best practices paragraph in the choices argument reference would go very far in making the awkwardness go away. 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 05/04/2012, at 12:20 AM, Adrian Holovaty wrote: > On Wed, Apr 4, 2012 at 9:57 AM, Jacob Kaplan-Moss wrote: >> On Wednesday, April 4, 2012 at 9:44 AM, Russell Keith-Magee wrote: >> >> 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. >> >> As the original author and designer of that pattern, I should probably point >> out that I now think it's a mistake. Have you actually tried using it? It >> doesn't really work very well. Every time I've introduced any sort of >> "swappable model" mechanism I've come to regret it. > > Totally agree with Jacob here, plus Tai's comment that "There is such > a thing as too generic." We've made the mistake of making things too > generic in the past, and it's kind of infuriating in retrospect, both > philosophically and in terms of code maintenance/understanding. > (django/utils/tree.py, anyone??) > > I think our policy should be: make the simplest thing that can > possibly work for a narrowly-tailored use case, then make things more > generic *slowly* if there's a demand. No need to be an Architecture > Astronaut. Certainly agreed that astronauting is a bad thing. However, I would like to draw attention to one particular benefit of the generic solution (other than being generic): Once we make User swappable, every app with a model that has a ForeignKey to User will need to be updated. This can be done slowly; existing projects that use auth.User will continue to work. However there won't be any real alert to the fact that the app requires updating until you try to swap out User and things start to break. This breakage will be somewhat unpredictable -- you'll just be observing side effect errors as a result of a non-existent (or empty) auth_user table. Under the approach I described, User will be marked (in the Meta object) as swappable, and ForeignKey(User) will be a hard link to a swapapble model, which is something we can catch as a validation warning, providing a cue to developers that there are apps in their project that may need to be updated. And if there is a ForeignKey(User) and settings.USER_MODEL *isn't* User, then we can raise an validation error, because we know that this app won't work. Even if we don't implement a fully generic solution, I think this property of the generic approach is worth preserving. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: auth.user refactor: the profile aproach
Are we really sure that we can or should stomach a swappable User model as a special case? It's highly likely that I am missing something (or a few things), but aren't the main benefits of swapping the User model just to avoid making a backwards incompatible change, and to avoid making `select_related()` queries? I'm not suggesting that backwards incompatibility is not important, but I'm not convinced by the argument about inefficient `select_related()` queries, and whatever we do will involve manual schema migration for many users. Do we really need to allow users to swap in their own model with a combination of additional project level fields as well as additional fields required by various pluggable apps as the primary `User` model, instead of simply stripping out authentication and identifying fields from the primary `User` model and allowing users to implement whatever they need as app or project level profile models? The more I think about it, the more I think this will just lead to more fragmentation and incompatibilities with pluggable apps, when the user "interface" is abused or causes conflicts. What's going to happen when this is rolled out and people start developing an eco-system of pluggable apps without a concrete `User` model in Django? All they can rely on is that there will be some form of `User` model and that it *should* provide at least a minimal set of fields and behaviours as specified by some guidelines in Django docs? Won't we just be back at square 1 in deciding what to include in the minimal fields and guidelines for the this "contract"? Isn't the only sensible minimal set of fields, no fields at all? Pluggable apps will have to either dictate to developers in the installation instructions that their particular `User` model must have certain fields or behaviours that are required by the pluggable app, which may even conflict with other pluggable apps. Or they will still have to fallback to using an app-profile model, which brings us back to using `select_related()` anyway. I don't like the idea that a pluggable app might require users to change their existing models like this. If pluggable apps will still need to use app-profile models anyway, if we can get past the backwards incompatibility issue, what is so bad about simply having a `User` model which has no auth or identity data in it, but is just there as glue for for apps to share data for a single "user"? Bundled apps like the admin would define `AdminProfile` and any pluggable apps that require or support the admin could access `user.admin_profile`. Pluggable apps that don't use the admin and/or have their own auth or identifying requirements can just ship with their own profile and/or auth models and optional auth backend. The only real issue I have with Django users/auth as it is right now is that there are redundant (for me) or non-compliant (with RFC) fields in `auth.User` that are required and that I have to fake in order to hook into the admin, groups and permissions or re-specify in my own profile for RFC-compliance. The other problem I have seen mentioned with the profile approach is managing common fields (e.g. two pluggable apps that have a "name" field). I'm quite happy for this to be managed by the developer at a project level, either using signals or forms or a `save()` method on their profile model or whatever else they like to keep that data in sync, if it needs to be kept in sync. I don't think pluggable apps requiring that developers have a "name" (for example) field on their primary `User` model is really a good solution to this problem, because the pluggable app doesn't know what other purpose that field is used for, and doesn't know if it is changed in app1 if it will have any consequences for app2. If developers really want a single project level `User` model, they can still create that (with an FK back to Django's `User` model), and simply update it's `save()` method to sync any common fields on all the pluggable app's profile models (which may even have different field names). E.g. `project.User` could have `first_name` and `last_name`, but app1 has only `name`, and app2 has `given_name` and `family_name`. In `project.User.save()`, the developer of a project can determine how to sync this data. Cheers. Tai. On Thursday, 5 April 2012 00:57:57 UTC+10, Jacob Kaplan-Moss wrote: > > On Wednesday, April 4, 2012 at 9:44 AM, Russell Keith-Magee wrote: > > 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. > > As the original author and designer of that pattern, I should probably > point out that I now think it's a mistake. Have you actually tried using > it? It doesn't really work very well. Every time I've introduced any sort > of "swappable model" mechanism I've come to regret it. > > I'm -1 on the idea of generalized
Re: [GSoC 2012] auth.User replacement proposal
On Wednesday, April 4, 2012 at 7:19 PM, Alex Ogier wrote: > Fair enough. My goal was never to shut down collaboration, and if GSoC will > do that then I am happy to drop it. The money was never my motivation, and I > will definitely still contribute what I can. > > > Yeah, I know -- it's a requirement of GSoC that can sometimes bite us. I understand the intention -- they want to be sure students are the ones actually doing the work -- but it can be annoying for projects like this. 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: auth.user refactor: the profile aproach
LazyForeignKey will not solve any problem that can't be solved now, and we have to introduce a new concept. It sounds like, when we encounted a hard problem, we give it a new name, instead of trying to solve it. Moreover, to support multiple user models, each app should be able to link to a different user model, LazyForeignKey can't be any help. Maybe the only way to solve this is to add a schema migration tool. When schema migration tool found a ForeignKey link to a different model than before, it raises a error, then I know there is something wrong. On Apr 5, 8:45 am, Russell Keith-Magee wrote: > On 05/04/2012, at 12:20 AM, Adrian Holovaty wrote: > > > > > > > > > > > On Wed, Apr 4, 2012 at 9:57 AM, Jacob Kaplan-Moss > > wrote: > >> On Wednesday, April 4, 2012 at 9:44 AM, Russell Keith-Magee wrote: > > >> 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. > > >> As the original author and designer of that pattern, I should probably > >> point > >> out that I now think it's a mistake. Have you actually tried using it? It > >> doesn't really work very well. Every time I've introduced any sort of > >> "swappable model" mechanism I've come to regret it. > > > Totally agree with Jacob here, plus Tai's comment that "There is such > > a thing as too generic." We've made the mistake of making things too > > generic in the past, and it's kind of infuriating in retrospect, both > > philosophically and in terms of code maintenance/understanding. > > (django/utils/tree.py, anyone??) > > > I think our policy should be: make the simplest thing that can > > possibly work for a narrowly-tailored use case, then make things more > > generic *slowly* if there's a demand. No need to be an Architecture > > Astronaut. > > Certainly agreed that astronauting is a bad thing. > > However, I would like to draw attention to one particular benefit of the > generic solution (other than being generic): > > Once we make User swappable, every app with a model that has a ForeignKey to > User will need to be updated. This can be done slowly; existing projects that > use auth.User will continue to work. However there won't be any real alert to > the fact that the app requires updating until you try to swap out User and > things start to break. This breakage will be somewhat unpredictable -- you'll > just be observing side effect errors as a result of a non-existent (or empty) > auth_user table. > > Under the approach I described, User will be marked (in the Meta object) as > swappable, and ForeignKey(User) will be a hard link to a swapapble model, > which is something we can catch as a validation warning, providing a cue to > developers that there are apps in their project that may need to be updated. > And if there is a ForeignKey(User) and settings.USER_MODEL *isn't* User, then > we can raise an validation error, because we know that this app won't work. > > Even if we don't implement a fully generic solution, I think this property of > the generic approach is worth preserving. > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: upgrading the choices machinery for Django
I generally like this idea, except for the implicit integer ids based on declaration order. As people have said, it seems like just asking for data corruption. I'd much rather see implicit character ids based on the attribute name of the choice, analogous to django fields. Will you be making this project available as a third-party app? --Stephen On Apr 4, 5:41 pm, Alex Ogier wrote: > On Wed, Apr 4, 2012 at 5:18 PM, Łukasz Langa wrote: > > Wiadomość napisana przez Daniel Greenfeld w dniu 4 kwi 2012, o godz. 22:48: > > > > On two occasions now I've had to do serious debugging on implementations > > done by other people who used a technique not dissimilar to what Łukasz > > proposes. In both cases, while the inheritance and better control > > structures were nice, the issue was that if you give people enough rope to > > hang themselves, they will. > > > Can you elaborate on that a bit? Even if the proposal is rejected in the > > end, I might use your experience to at least make the rope less deadly. > > I imagine a big one is that without an explicit database representation for > every item, it is easy to get out of sync with the real data you have. And > when that happens, there isn't necessarily a good way of retrieving the > meaning of old data: if some data in your database says that you are using > license '302' but that index was implicitly auto-generated by the > particular ordering of Choice() instantiations, then when the ordering > changes you can lose track (and indexing based on an implicit ordering of > class attributes definitely seems shaky to me). > > When I use enumerated fields, I generally make them VARCHAR(10) or so, and > then use plain English, potentially abbreviated, for a database > representation. That makes for reasonable code, "if self.license == > 'gpl_any':" looks very readable to me, and doesn't restrict you from > altering display values for internationalization. > > It seems to me like this is really a documentation problem, where > distilling the wisdom of developers like Adrian into a little best > practices paragraph in the choices argument reference would go very far in > making the awkwardness go away. > > 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.