Re: Proposal django.db schema alteration
On Apr 7, 2:09 am, Russell Keith-Magee wrote: > On Thu, Apr 7, 2011 at 1:47 AM, xtrqt wrote: > However, we can't let you get away without asking at least one question [1] > :-) > > [1]http://djangocaptions.com/post/647587573 Nice picture ;) > Can you clarify your approach a little bit here? Are you proposing to > completely deprecate the existing backend.creation interface in favor > of a new "metaoperations" module? Or are you going to keep the old > creation module and introduce a new module that contains the 'missing' > operations like rename and alter? Or something else entirely? I haven't made myself clear about that, but I would like to introduce new features as an optional, 'publicly' available layer of API, old SQL generating API would persist as long as we need it, but would become `internal internal` in comparison to `internal but almost public` new API. We could think about different scenario, like you suggested, that old interface is redirect to new one, but the major problem is that in new solution, we operate on higher abstraction level (it means we consider no "SQL" abstract) than in old one. So to make these redirection possible, we would need, sql_create_model -> [model_definition] -> create_model -> [created Model in database, not commited] -> get_sql_for_table -> [sql for Model] -> rollback transaction -> [sql_code_returned] quite much overhead, but not impossible. So old functions [creation func.] will be preserved as they were coded, so for some time old applications that were using this old fashion of calls would still work. On the other hand we should note that this should be only for transition between 1.3-1.4. Applications written in 1.4, should take in account only new interface. So we can refactor [I can see my role in that] creation code to match style of alteration code just before 1.5 release. And as I said before, Django use it's creation interface only in 2 places so it shouldn't be hard to move this code to new call convention. I hope I have answered all your questions. I'm still open for new questions ;) best regards xtrqt -- 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] Composite fields: proposal draft 1, full version
On Thu, Apr 7, 2011 at 2:51 AM, Michal Petrucha wrote: > GSoC 2011 Proposal: Composite Fields > Hi Michal, This looks to be a fairly solid proposal. You've done a lot of detailed research, and while I'm almost completely certain you'll find some gremlin lurking underneath some dark corner of the code, you appear to have a good grasp on the scope of the problem you're proposing to solve. A couple of quick comments: > Relationship fields > ~~~ > > This turns out to be, not too surprisingly, the toughest problem. The fact > that related fields are spread across about fifteen different classes, > most of which are quite nontrivial, makes the whole bundle pretty fragile, > which means the changes have to be made carefully not to break anything. Feel free to do some housekeeping while you're in there :-) The internal structure of foreign keys and m2ms isn't officially stable API, so you have some liberty to do some cleanup. > This infrastructure will allow reimplementing the GenericForeignKey as a > CompositeField at a later stage. Thanks to the modifications in the > joining code it should also be possible to implement bidirectional generic > relationship traversal in QuerySet filters. This is, however, out of scope > of this project. This, for me, is ultimately one of the biggest areas for gain. Adding the new features of composite FKs and PKs will certainly be a big benefit, cleaning up the special case handling for Generic Foreign Keys will be a much bigger architectural win. I appreciate that you have to draw the line somewhere; but I suspect that you may be faced with the need to modify an interface in a way that will make it easier to handle CompositeFields, but breaks the existing implementation of Generic Keys. If this happens, updating GenericKeys may be an inevitable consequence. > As I will have quite a few exams at school throughout June, I won't be > able to commit myself fully to the project for the first month and will > spend approximately 20 hours per week during this period. By the end of > the exam period, however, I intend to have sped up to about 30-35 hours > per week. I don't have any problem with this; it's an unfortunate consequence of European school terms. However, we've historically encouraged applicants to stretch the rules a little bit, and start early on their project so they can compensate for at least some of the time they lose during exams. > The proposed timeline is as follows: > > week 1 (May 23. - May 29.): > - basic CompositeField implementation with assignment and retrieval > - documentation for the new field type API > > week 2 (May 30. - Jun 5.): > - creation of indexes on the database > - unique conditions checking regression tests > > week 3 (Jun 6. - Jun 12.): > - query code refactoring to make it possible to support the required > extra_filters > - lookups by CompositeFields > > week 4 (Jun 13. - Jun 19.): > - creation of a composite primary key > - more tests and taking care of any missing/forgotten documentation so far > > week 5 (Jun 20. - Jun 26.): > - ModelForms and GFK support for composite primary keys > > week 6 (Jun 27. - Jul 3.): > - full support in the admin Weeks 5 and 6 seem particularly ambitious -- not completely impossible, mind; just very ambitious. > week 7 (Jul 4. - Jul 10.): > - fixing any documentation discrepancies and making sure everything is > tested thoroughly > - exploring the related fields in detail and working up a detailed plan > for the following changes > > > midterm > By the time midterm evaluation arrives, everything except for > relationship fields should be in production-ready state. > > week 8 (Jul 11. - Jul 17.): > - implementing composite primary key support in all the > RelatedObjectDescriptors > > week 9 (Jul 18. - Jul 24.): > - query joins refactoring > - support for ForeignKey relationship traversals Again -- another ambitious week. > week 10 (Jul 25. - Jul 31.): > - making sure OneToOne and ManyToMany work as well > > weeks 11&12 (Aug 1. - Aug 14.): > - writing even more tests for the relationships > - finishing any missing documentation > > > pencils down > > As can be seen from the proposed timeline, there is a separation between > the part that leads up to admin support for composite primary keys and the > relationship part. In my opinion the first part is more likely to be used > in practice than the second part so the main emphasis will be put on it in > case I discover unexpected difficulties. However, looking at the timeline > broken down into small parts I'm confident all proposed features should be > possible in the given time. Given the ambitious nature of this project, it's good that you've considered the worst case scenario, and you have a plan for handling it. Just to clarify -- my understanding is that if the project only got as far as it's midterm goals, it would be possible to define a CompositeKey (primary or
Re: Using OneToOneField in reverse from values or values_list is rejected with "Invalid field name" (repost)
On Tue, Apr 5, 2011 at 10:09 PM, Matt Hoskins wrote: > My apologies for reposting this - I originally posted this at the end > of January and as soon as I posted it I realised that with the push > for bug squashing for the 1.3 release going on I probably wouldn't get > any attention (and thus comment or replies :), so I'm trying a repost > now that 1.3 is out. If someone knowledgeable about the query code in > django could comment on whether the behaviour is by design or an > oversight that would be useful! > > (Below where I say "reverse name" I mean using that reverse name from > the model that the OneToOneField relates to) > - > Working on some code I've hit that the reverse name for a > OneToOneField cannot be used, it seems, in values_list or values. I > couldn't see why there would need to be such an exclusion, given it is > a one-to-one relationship, so am wondering if it's just an oversight > in the code or a deliberate exclusion? I'd need to go spelunking through the code to be sure, but if this is happening, I'd be guessing it's oversight. From a quick scan of the test suite, I can't find an obvious test for values() on one-to-one fields. As for the reason for this; OneToOne keys are a degenerate case of foreign key, but in the reverse direction, they have a single value (as opposed to the multiple values of a reverse foreign key). As a result, the oversight would be failing to include reverse one-to-ones in the list of valid names, overriding the default interpretation for the ForeignKey from which they are inherited. So - it sounds like this should be reported as a ticket; If you could also reduce this to a test case that is integrated into Django's test suite (regressiontests/one_to_one_regress would be a good place, because it has o2o models ready to use), that would be very helpful. 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: HttpRequest.read() issues
> So, OP should not be trying to read more than CONTENT_LENGTH. >From the underlying stream, sure. The question is if it's okay to do on the HttpRequest object. It's an issue because now that HttpRequest exposes a file-like interface to the stream some users are likely to do things like this: request_data = json.load(request) And expect that everything should work fine. > Django should provide a limited stream to prevent user reading more > than CONTENT_LENGTH either by returning an empty end sentinel, > or perhaps if wanted to be pedantic, raise an error. And it does currently provide a limited stream, in some cases, but for (very reasonable) performance reasons, only when it appears neccessary. > Now they just seem to be duplicates > and it's a good idea to ditch LimitBytes (since LimitedStream implements > a readline() too) and move it into some common place. http.utils seems a > good fit for it. Moving LimitedStream to somewhere like http.utils sounds like a good plan to me. > Thoughts? I think HttpRequest definatly needs to ensure that it's safe to treat it as any other file-like object, now that it exposes the .read()/.readlines() methods, and at the moment it sounds like the behaviour of .read(BUFFER_SIZE) past the end of the input is not well defined. 1. It might be reasonable to defer the creation of HttpRequest._stream, but to _always_ wrap it in LimitedStream if it is created. (IE HttpRequest._stream is a property that's only initialised when it's accessed) That'd presumably be a performance gain for any code path that _doesn't_ access .POST/.raw_post_data/.read, and a performance hit for anything that _does_. In 99% of cases you'll be doing a .read() operation without specifying any length at all so the performance hit will be the initial creation of the LimitedStream object, but you won't actually have subsequent function calls that incur the extra layer of wrapping. 2. Ensure that the .read()/.readline() interfaces will always expose a LimitedStream, but avoid creating a limited stream for .POST and .raw_post_data by reading directly from the underlying stream and enforcing the CONTENT_LENGTH behavior explicitly in those cases. 3. Alter the LimitedStream wrapping behaviour to be more cautious. The current behaviour is to wrap it in LimitedStream if it's known to be necessary.It could instead wrap it in LimitedStream _unless_ it's known to be _uneccessary_. Do any of those sound like reasonable options? I guess the other possibility is: 4. Everything is fine as it is, and in real world cases WSGI servers are passing a limited stream on already. It basically sounds like that's the case, but it's not obvious how much we can rely on that. It might be a case that I need to file a seperate bug for this: HttpRequest.read(BUFFER_SIZE) behaviour is unclear. and place a note on the other two that their resolution is dependant on this, does that make sense to y'all? Really appreciate your input on this, 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: HttpRequest.read() issues
Actually it occurs to me that (1) shouldn't be a performance hit for accessing .POST either, because whilst you're now creating a LimitedStream, you're able to drop MultiPartParser's use of LimitBytes. -- 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: HttpRequest.read() issues
It occurs to me that (1) isn't a hit for accessing multipart POST requests, since we're wrapping the underlying stream in LimitedStream, but beng able to drop MultiPartParser's use of LimitBytes. -- 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: Using OneToOneField in reverse from values or values_list is rejected with "Invalid field name" (repost)
On Apr 6, 12:09 am, Matt Hoskins wrote:
> My apologies for reposting this - I originally posted this at the end
> of January and as soon as I posted it I realised that with the push
> for bug squashing for the 1.3 release going on I probably wouldn't get
> any attention (and thus comment or replies :), so I'm trying a repost
> now that 1.3 is out. If someone knowledgeable about the query code in
> django could comment on whether the behaviour is by design or an
> oversight that would be useful!
>
> (Below where I say "reverse name" I mean using that reverse name from
> the model that the OneToOneField relates to)
> -
> Working on some code I've hit that the reverse name for a
> OneToOneField cannot be used, it seems, in values_list or values. I
> couldn't see why there would need to be such an exclusion, given it is
> a one-to-one relationship, so am wondering if it's just an oversight
> in the code or a deliberate exclusion?
>
> The portion of code that is rejecting doing e.g.
> "values_list('onetoonereversename')" is in setup_joins where the if
> line reads:
>
> if not allow_many and (m2m or not direct):
>
> The values of "m2m" and "direct" come from opts.get_field_by_name and
> it seems that the reverse of a OneToOne gives the same results as the
> reverse of a ForeignKey, as of course both are not m2m and are not
> direct. Looking at the code later on in setup_joins it describes the
> path where direct is false and m2m is false as being "One-to-many
> field (ForeignKey defined on the target model)", so it looks like the
> logic I've quoted above of "if not allow_many and (m2m or not direct)"
> has the "not direct" clause in to reject reverse ForeignKey
> relationships and in doing so also rejects reverse OneToOne
> relationships (and with the latter case I suspect it need not!).
>
> If someone a bit more knowledgeable about the query machinery could
> comment on whether it does look like an oversight or is a deliberate
> exclusion, then if it's the former I'll log it as a bug.
>
> Assuming the rest of the code is ok in the case of a reverse OneToOne
> then something along the lines of "if not allow_many and (m2m or (not
> direct and not isinstance(getattr(field,'field',None),OneToOneField))"
> instead could work to allow OneToOne reverses through in setup_joins
> when allow_many is False.
>
> Regards,
> Matt
Hi Matt,
Do you think this could be related to http://code.djangoproject.com/ticket/11448
?
If so, do the patches attached to that ticket help resolve your issue?
Thanks,
Julien
--
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: HttpRequest.read() issues
Silly question. Where is the proof that using a limited stream is a performance issue? These sorts of things are never going to be the bottleneck and sounds a bit like premature optimisation to think that wrapping it with a length limiting stream is going to be an issue. Graham On Thursday, April 7, 2011 6:56:35 PM UTC+10, Tom Christie wrote: > > > So, OP should not be trying to read more than CONTENT_LENGTH. > > From the underlying stream, sure. The question is if it's okay to do on > the HttpRequest object. It's an issue because now that HttpRequest exposes > a file-like interface to the stream some users are likely to do things like > this: > > request_data = json.load(request) > > And expect that everything should work fine. > > > Django should provide a limited stream to prevent user reading more > > than CONTENT_LENGTH either by returning an empty end sentinel, > > or perhaps if wanted to be pedantic, raise an error. > > And it does currently provide a limited stream, in some cases, but for > (very reasonable) performance reasons, only when it appears neccessary. > > > Now they just seem to be duplicates > > and it's a good idea to ditch LimitBytes (since LimitedStream implements > > a readline() too) and move it into some common place. http.utils seems a > > good fit for it. > > Moving LimitedStream to somewhere like http.utils sounds like a good plan > to me. > > > Thoughts? > > I think HttpRequest definatly needs to ensure that it's safe to treat it as > any other file-like object, now that it exposes the .read()/.readlines() > methods, and at the moment it sounds like the behaviour of > .read(BUFFER_SIZE) past the end of the input is not well defined. > > 1. It might be reasonable to defer the creation of HttpRequest._stream, but > to _always_ wrap it in LimitedStream if it is created. (IE > HttpRequest._stream is a property that's only initialised when it's > accessed) That'd presumably be a performance gain for any code path that > _doesn't_ access .POST/.raw_post_data/.read, and a performance hit for > anything that _does_. In 99% of cases you'll be doing a .read() operation > without specifying any length at all so the performance hit will be the > initial creation of the LimitedStream object, but you won't actually have > subsequent function calls that incur the extra layer of wrapping. > > 2. Ensure that the .read()/.readline() interfaces will always expose a > LimitedStream, but avoid creating a limited stream for .POST and > .raw_post_data by reading directly from the underlying stream and enforcing > the CONTENT_LENGTH behavior explicitly in those cases. > > 3. Alter the LimitedStream wrapping behaviour to be more cautious. The > current behaviour is to wrap it in LimitedStream if it's known to be > necessary.It could instead wrap it in LimitedStream _unless_ it's known > to be _uneccessary_. > > Do any of those sound like reasonable options? > > I guess the other possibility is: > > 4. Everything is fine as it is, and in real world cases WSGI servers are > passing a limited stream on already. > > It basically sounds like that's the case, but it's not obvious how much we > can rely on that. > > It might be a case that I need to file a seperate bug for this: > > HttpRequest.read(BUFFER_SIZE) behaviour is unclear. > > and place a note on the other two that their resolution is dependant on > this, does that make sense to y'all? > > Really appreciate your input on this, > > 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: HttpRequest.read() issues
> Where is the proof that using a limited stream is a performance issue? These sorts of things are never going to be the bottleneck and sounds a bit like premature optimisation to think that wrapping it with a length limiting stream is going to be an issue. There isn't any, so good point. :) Even so, presumably we wouldn't want WSGIRequest to create a LimitedStream object for _every_ single incoming HTTP request, regardless of if it actually has a payload or not? In that case deferring the LimitedStream creation, but always ensuring that HttpRequest._stream is a LimitedStream rather than the underlying stream would be a sensible thing to do. It's fairly simple logic, and it's guaranteed to be a safe thing to do. I'd be happy to code up a patch for this, if we reckon that's a sensible approach. -- 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 Proposal] Read-only forms and DataBrowse
[GSoC Proposal] Read-only forms and DataBrowse == About Me -- I'm a college student of computer engineering at the Universidad Politécnica de Madrid. This will be my last year before I graduate. I started programming websites six years ago in PHP and various frameworks like Zend Framework among others. Since I came across Django (v1.0) it is the only thing I've used. I have developed a bunch of things in Django including some small commits to Zinnia. I have a good understanding of Python and today I want to show you a proposal. I hope you like it. You can see this proposal in HTML here http://sysvar.net/gsoc2011/proposal_1.html Problem Description -- The addition of the `newforms` package to Django greatly improved the use of these since the last model. My proposal seeks to fix some of the existing problems and at the same time implement some new features to Django. As it is stated in the Django ideas site for the GSoC one of the remaining tasks is integrating the `django.contrib.databrowse` module into the administration, allowing among other things a read-only administration. My solution is not to integrate the module but to go a little further and allow forms to render in read-only mode (without showing their widget). This would result in various things: * A lot of web applications need to show the same form in two modes: write and read. Django is currently set up in a way the edition part would be already resolved, but the layout of the reading part has to be done manually. With this fix both parts can be done within the same form. * The administration could be viewed in read-only mode without too much coding. A new perm could be implemented (`can_read_xxx`) so if a user had it, he could navigate the administration without the possibility of changing the inputs. This way the need to integrate the databrowse module would be satisfied (without actually doing it). * Pushing things further, I propose the extension of the form perms so each input can be individually selected whether if they need to show up as read or write. If forms come from models they would have in consideration the `editable` attribute. These modes could be dinamically specifed, so that you could choose to leave certain inputs only to some users, while others could only see them in read mode. * Lastly, I propose making the rendering of all the inputs smarter to replicate the 'magic' achieved by the databrowse module. In a similar way to the `get_xxx_display` method available to lists, it would be wise for every field to be able to choose how they will render in read- only mode. In a simple example, we want a `ForeignKey` to be rendered in read mode with a link to it's object. This way a few will be shipped by default (like the ForeignKey ones) but it will be up to the developer to choose how he wants to draw his inputs. This will result in inputs being draw in a constant fashion **all along the website** and not only the administration. With this improvement in the forms we fixed the `databrowse` problem, including all the considered issues like the customization of the display with fields, fieldsets, ... because forms will still work the same way. Besides, with this solution all forms will be provided with the same powers, not just the ones in the administration. Implementation Plan -- This proposal has two distinct parts. In the first one I seek to extend the forms in Django so they are allowed to be rendered in read-only mode. For this, I propose adapting the code that has to do with the rendering, `_html_output` for example. In this first part there are no major problems because all the form is in read-only mode and we don't have to battle form validations. A new perm will be made `can_view` so the administration will be fully functional in read-only mode. To allow forms to be completely rendered in read-only mode I propose the creation of methods similar to the ones that already exist, for example `as_ul_display`. Lastly the intelligent rendering mode will be implemented (as in the previous ForeignKey example), extending the model so the user can define how he wants the inputs to render (or leave Django sort it out on his own). The second part will be focused to implement individual perms for each input, so users can only edit the ones they are allowed, while still being able to see the others. In this part any problem with form validations will be resolved, except in those the user can't write. Timeline -- Whilst studying I have enough time, virtually all in summer, in exception of the first weeks of June, when I have exams. * 2 weeks Research, design and discuss all the stuff related to the proposal (for the two parts). * 3 weeks Coding the upgrade for the forms to a
Re: [GSoC Proposal] Read-only forms and DataBrowse
On Thu, Apr 7, 2011 at 5:04 PM, igalarzab wrote: > [GSoC Proposal] Read-only forms and DataBrowse > == > > Problem Description > -- > The addition of the `newforms` package to Django greatly improved the > use > of these since the last model. > > My proposal seeks to fix some of the existing problems and at the same > time > implement some new features to Django. > As it is stated in the Django ideas site for the GSoC one of the > remaining tasks is integrating the `django.contrib.databrowse` module > into > the administration, allowing among other things a read-only > administration. > My solution is not to integrate the module but to go a little further > and > allow forms to render in read-only mode (without showing their > widget). What you're proposing here is quite different from what the GSoC wiki proposes. The wiki refers to about adding read permissions to the admin, and providing browsing capability for data within the admin. Your proposal is to add read-only widgets -- a feature that the admin already has, and has been historically rejected as part of the core forms library. If you're going to propose a project that has historically been rejected, you may want to provide some counterargument to the reasons it has been historically rejected. Ideally, this discussion should have started several weeks ago, so you could demonstrate that there is now community acceptance for the idea you are proposing. > Timeline > -- > Whilst studying I have enough time, virtually all in summer, in > exception of the > first weeks of June, when I have exams. > > * 2 weeks > > Research, design and discuss all the stuff related to the proposal > (for the two parts). This is also a red flag for me. Research and design is what you do *before* you apply, not something that takes up 1/6 of the allotted time for the GSoC. If you haven't done any research and design, how can you have any confidence that your work estimates for the rest of the project are even remotely accurate? In short -- this doesn't seem like a particularly viable proposal in it's current form. 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 Proposal] Read-only forms and DataBrowse
On Thursday, April 7, 2011 at 13:55 , Russell Keith-Magee wrote: > On Thu, Apr 7, 2011 at 5:04 PM, igalarzab wrote: > > [GSoC Proposal] Read-only forms and DataBrowse > > == > > > > > Problem Description > > -- > > The addition of the `newforms` package to Django greatly improved the > > use > > of these since the last model. > > > > My proposal seeks to fix some of the existing problems and at the same > > time > > implement some new features to Django. > > As it is stated in the Django ideas site for the GSoC one of the > > remaining tasks is integrating the `django.contrib.databrowse` module > > into > > the administration, allowing among other things a read-only > > administration. > > My solution is not to integrate the module but to go a little further > > and > > allow forms to render in read-only mode (without showing their > > widget). > > What you're proposing here is quite different from what the GSoC wiki > proposes. The wiki refers to about adding read permissions to the > admin, and providing browsing capability for data within the admin. > > Your proposal is to add read-only widgets -- a feature that the admin > already has, and has been historically rejected as part of the core > forms library. > > If you're going to propose a project that has historically been > rejected, you may want to provide some counterargument to the reasons > it has been historically rejected. Ideally, this discussion should > have started several weeks ago, so you could demonstrate that there is > now community acceptance for the idea you are proposing. > > > Timeline > > -- > > Whilst studying I have enough time, virtually all in summer, in > > exception of the > > first weeks of June, when I have exams. > > > > * 2 weeks > > > > Research, design and discuss all the stuff related to the proposal > > (for the two parts). > > This is also a red flag for me. Research and design is what you do > *before* you apply, not something that takes up 1/6 of the allotted > time for the GSoC. If you haven't done any research and design, how > can you have any confidence that your work estimates for the rest of > the project are even remotely accurate? The design and research is done. The time was meant to be used for discussion with the rest of the developers. Anyhow as you point out, if it has been historically rejected I have nothing more say about this :) Thank you. > In short -- this doesn't seem like a particularly viable proposal in > it's current form. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Read-only forms and DataBrowse
About the read-only forms part of the proposal: read-only forms will
be easy to implement if the template widget rendering idea will be
included in core.
For example for SelectMultiple widget the base template is probably
something like this:
{% for choice in choices %}
{% if choice.selected %}
{{choice}}
{% else %}
{{choice}}
{% endif %}
{% endfor %}
If you want a read-only widget, just give it a custom template:
{% for choice in choices %}
{% if choice.selected %}
{{choice}}
{% endif %}
{% endfor %}
Now, that was easy :) Combined with template based form rendering, it
would be relatively easy to implement read-only forms. Another reason
why template based form/widget rendering would be nice to have in
core.
By the way, it would be nice to see how the template based rendering
compares to python based rendering in performance terms when rendering
a larger list of choices. But on the other hand, if you have a large
Select/SelectMultiple list there is bound to be some usability issues,
so maybe the performance isn't that important... Sorry for bringing
performance up here again, but I am a speed freak :)
For what it's worth, I implemented somewhat working read-only fields /
widgets some time ago. I have used it a little in some sites, and the
ability to render any model / form easily in display-only mode is a
really nice feature. The work can be found at [1], but it is
incomplete and based on an old version of Django (last commit is from
August 23, 2010).
[1] https://github.com/akaariai/django/tree/ticket10427
- 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] Composite fields: proposal, part 1
On Thu, Apr 07, 2011 at 12:38:07AM +0200, Johannes Dollinger wrote: > The only downside is that you'll have to pick a name for the index – > even if you don't really care (that's historically been a problem > with `related_name`). But anyway, since Meta.unique_together > probably cannot be deprecated any time soon, that's just a -0 from > me. You're right, having to choose a name for an index might seem weird. Maybe the deprecation of unique_together wouldn't be necessary. This reminds me of a certain comment in the related fields code, [1] > I don't want to push my proposal into your GSoC project. It'd > require more thought and discussion before I'd suggest that. > To address your concern: fields are a central component of the ORM. > But currently, instead of using methods to encapsulate field > specific logic, everything is stuffed in a single monolithic class > (Query), that has to know every possible field implementation. This > leads to code that is hard to maintain and requires coupling with > code that needs more control than standard fields (read: > contenttypes). > And since `add_lookup` and a bit of public API on Query would make > it possible to implement most of your proposal without touching > Django, I wanted to propose it soon enough to have a possible > influence on design decisions. There is certainly a point in this. On the other hand, moving some of the SQL logic would make life harder for the guys fighting on the non-relational backend front. I don't know much about the state of this area though... > Regardless, I look forward to CompositeFields. Good luck with your > application! Thanks. (-; Michal [1] http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/related.py#L1087 signature.asc Description: Digital signature
Re: Read-only forms and DataBrowse
On Thu, Apr 7, 2011 at 3:23 PM, akaariai wrote:
> About the read-only forms part of the proposal: read-only forms will
> be easy to implement if the template widget rendering idea will be
> included in core.
>
> For example for SelectMultiple widget the base template is probably
> something like this:
>
>
> {% for choice in choices %}
> {% if choice.selected %}
> {{choice}} option>
> {% else %}
> {{choice}}
> {% endif %}
> {% endfor %}
>
>
> If you want a read-only widget, just give it a custom template:
>
>
> {% for choice in choices %}
> {% if choice.selected %}
> {{choice}}
> {% endif %}
> {% endfor %}
>
>
> Now, that was easy :) Combined with template based form rendering, it
> would be relatively easy to implement read-only forms. Another reason
> why template based form/widget rendering would be nice to have in
> core.
>
> By the way, it would be nice to see how the template based rendering
> compares to python based rendering in performance terms when rendering
> a larger list of choices. But on the other hand, if you have a large
> Select/SelectMultiple list there is bound to be some usability issues,
> so maybe the performance isn't that important... Sorry for bringing
> performance up here again, but I am a speed freak :)
If you want to play with template-based widgets and benchmarks, feel
free to look at my github fork [0]. This is where I'm implementing
template-based widgets (http://code.djangoproject.com/ticket/15667)
and I added a few metrics in the last & only commit message. Timing
the forms regressiontests gives this (network calls excluded):
* No template caching: Ran 402 tests in 2.395s
* Template caching: Ran 402 tests in 1.413s
* Old string-based method: Ran 402 tests in 0.864s
If you're interested in measuring the impacts in more details, feel
free to dig and write benchmarks. I'm sure this would result in some
valuable information. I haven't converted the admin widgets yet but
measuring the effect on the admin test suite would also show the
impact on real-world applications.
Bruno
[0] https://github.com/brutasse/django/commits/15667-template-widgets
--
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] Revised form rendering
Sorry for the quite late response, everything is getting pretty close to the
deadline. I'm not happy with it but I need to tackle some personal issues at
once.
2011/4/5 Russell Keith-Magee :
>
> ...
>
> In particular, I have two objections:
> * it feels like it's trying to cram too much into a single template tag.
> * it requires a lot of duplication of "form myform configure" or
> "formblock myform using"
>
> Consider a slight variation that uses more tags:
>
> {% form myform configure %}
> {% layout "uni_form" %}
> {% widget "calendar" for DateField %}
> {% autocomplete "lastname" from "/users/lastnames" %}
> {% endform %}
Yes that looks clean and easy to follow. I just don't like the lone keyword
'configure' (or 'using') at the end of the tag. But I guess we need it to
determine if we search for a closing endform tag or if it's a standalone one
(or we use the 'trick' you described for the media handling).
> Then, when it comes time to render:
>
> {% form myform using %}
> {% field "firstname" %}
> And some HTML decoration
> {% field "lastname" %}
> {% endform %}
Looks good. A problem would be with using multiple forms:
{% form myform using %}
{% form another_form using %}
{% field "name" %}
{% endform %}
{% endform %}
Is "name" a field of "myform" or "another_form"? But thats easy to work around
by using {% field myform.name %} for example.
> or, using an iterative approach:
>
> {% form myform using %}
> {% for field in myform %}
> {% field field %}
> {% endfor %}
> {% endform %}
I wonder how it would look like to change the layout and outputting the whole
form like {{ form.as_ul }}. Your example is for more than basic scenarios good
but very verbose for just changing the layout. Maybe using the form tag would
inherit the configuration from the wrapping form tag::
{% form myform using %}
{% layout "ul" %}
{% form myform %}
{% endform %}
Skipping the wrapping {% form myform using %} is also possible, layout would
configure the whole template by setting a context variable. However this might
have sideeffects on included templates etc. Explicit is usually better than
implicit. But we will find a way to deal with it.
> or, using default layout:
>
> {% form myform %}
>
> This approach:
> * cuts down on the duplication, either in the form of indented form
> blocks, or in duplicated 'tag opening' content
> * avoids the need for a DSL embedded in the tag definition
> * avoids potential grammar ambiguities -- the less grammar there is
> in a tag, the less likely there will be edge cases in the parsing.
>
> ...
>
>>> Rendering modifiers
>>>
>>>
>> But like I already wrote above: I see your concerns with adding yet another
>> registry that might not be used very often. I would agree on dropping that
>> feature if you think its better to skip this until users demand it
>> afterwards.
>
> I think this might be the better approach. Your proposal is already
> fairly ambitious, especially if it's going to include a reworking of
> admin's rendering. And, to that end, reworking admin's rendering
> should prove a useful testbed for whether it is needed at all.
>
> Also -- some food for thought; the reason that a registry is needed
> here is because you're defining an extension api for a monolithic {%
> form %} tag. If the rendering strategy used multiple tags, modifiers
> could also be defined as template tags:
>
> {% form myform %}
> {% mymodifier foo %}
> {% endform %}
>
> Then you don't need a separate registry; a "modifier" just becomes a
> template tag operating on the API exposed by the form rendering API
> (presumably a set of known objects in the local context of the form
> tag). If an end user wants a rendering modifier, they just define
> their own template tag and use it in a {% form configure %} block.
Ha! That makes me happy to have a possibility for custom behaviour in the form
rendering and you happy because we don't need another abstraction. I like this
approach and will go for it.
>>> Form rows
>>> ~
>>>
>>> If you look at the existing as_* form layout tools, there is a
>>> distinction between gross form layout, and the layout of an individual
>>> form row.
>>>
>>> {{ form_header }}
>>> {% for field in form %}
>>> {{ pre_field }}}
>>> {{ field }}
>>> {{ post_field }}
>>> {% endfor %}
>>> {{ form_footer }}
>>>
>>> Conceptually, the rendering for pre/post field could vary depending on
>>> the field. How is this handled in your proposal? Is it part of the
>>> form renderer? Or part of the widget rendering? This overlaps with
>>> your discussion about error templates -- since errors (and their
>>> rendering) is one of the major pre/post rendering activities for both
>>> forms and fields.
>>
>> I'm not sure if I get your example right. Is it representing the output of a
>> "as_*" method? I looked into the django/forms/forms.py code again and I'm
>> quite sure that there is
Re: HttpRequest.read() issues
Okay, since there's clearly an underlying issue here I've created a seperate ticket for this and marked the other two tickets as duplicates of it. So... #15785 - HttpRequest.read(NUM_BYTES) can read beyond the end of wsgi.input stream. (Violation of WSGI spec & under-defined behaviour) [1] There is a patch (with tests) attached. [2] * Changes WSGIRequest._stream to be a property that is (always) instantiated as a LimitedStream when first accessed. * Removes some redundant code in HttpRequest and MultiPartParser. * Fixes some minor bugs in tests/regressiontests/requests/tests.py * Adds two tests for MultiPartParser to check graceful behaviour on truncated or empty multipart requests. * Adds a test for TestClient request.read(LARGE_BUFFER) behaviour. This fixes (#15762) without having to alter any test client code, and includes the fixes for (#15763) This looks like a decent way to do things to me - it's less code than before, it's safer, and it's easy to understand. I'd appreciate any eyeballs/kicking the tires etc... Whaddya reckon? t. [1] http://code.djangoproject.com/ticket/15785 [2] http://code.djangoproject.com/attachment/ticket/15785/limited_stream.diff NB. There's also some behaviour in MultiPartParser that could be adapted slightly to support streaming requests with unknown length. Obv that's mostly entirely pointless right now since WSGI won't support them anyway (yet?...) Right, as far as I understand it PEP doesn't address chunked requests, only chunked responses, so I guess this point is moot? -- 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] Composite fields: proposal, part 1
On Wed, Apr 06, 2011 at 04:57:39PM -0500, Jacob Kaplan-Moss wrote: > So far this looks pretty good to me. Assuming you get the rest done > with a similar level of detail I'll be voting to approve it (and > possibly signing up to mentor, time-willing). Thanks for the encouragement, I really appreciate it. > One thing I'd like to see a bit more of is a roundup of your previous > experience with Django and with open source in general. I can't keep > track of everyone who participates, so it's nice to remind me of where > I might have seen your name around before. If you haven't done much > yet that's totally fine. But if you've got a track record, brag about > it :) I'll update this section of the proposal, but I think I'll prioritize the implementation related parts today... > > One thing that bugs me is the name of the namedtuple -- it is a class, > > which means InitialCaps is the right way, however, its name is partly > > composed of a field name which underscore-separated words fit better. This > > is just a cosmetic detail though. > > Another thing to consider: namedtuple is only available in Python 2.6 > and above, so we'd have to backport it if we used it literally. It may > be better in the long-run to use a namedtuple-like "CompositeObject" > implementation of our own. In other words, don't feel bound to > namedtuple just because I used it. The code I wrote was a 10 minute > hack. > > So you may want in the proposal to describe the composite object as a > "namedtuple-like object" or something to indicate that it might be a > different type of object in the end. I don't think anyone particularly > cares about the particular implementation as long as they can say > ``person.name.first`` or whatever. Writing a small class shouldn't be any problem, I'll update that. > > QuerySet filtering > > ~~ > > > > This is where the real fun begins. > > Man you ain't kiddin' :) > > You've done a fine job describing the problem, and your solution > sounds reasonable to me as a sketch. > > But there's two things missing here for me: I'd like a description of which > query operators will be supported by composite keys. Clearly ``__exact`` would > be supported. Maybe ``__in``? But I'll bet composite fields will only support > a > couple-three operators, right? I think that's fine -- I can always > query the sub-fields directly themselves. > > It's important for you to remember that you don't have to get every > single feature done all in one fell swoop. Even if composite fields > only support ``__exact`` that's a huge win, and we can always add > support for other types of queries later. It's perfectly acceptable > for you to say things like "this feature might be possible but isn't > in scope". Yeah, I forgot to make it more explicit. I was considering the "__in" lookup at first, but in the end I decided it will only support "__exact". "__in" might be implemented later but it will require some more serious refactoring in the add_filter code and making the extra_filters more powerful. > Actually, now that I write that, it's not just acceptable -- it's > awesome. Defining what's *not* in scope is great because it helps > define what "success" is going to mean. Constraints are good :) > > > GenericForeignKeys > > ~~ > > > > As I said, this is used in the admin, which means we can't have full admin > > support without also making GenericForeignKeys work with CompositeFields. > > Hm, I'm not sure I understand what you mean here -- can you explain a > bit further? I'd think we can leave GFKs out as a to-be-done-later > thing. Remember: you've got two months to get code to the point that > we can merge it into trunk. The thing is, the admin uses ContentType in the LogEntry model. However, now that I'm looking at the code, it only uses ContentType.get_object_for_this_type which means making sure the primary key it passes as the parameter is an actual unpacked CompositeObject should be enough. I guess you're right, I'll leave this part for a later stage. Thanks for the comments, I'll try to post an updated version soon. Michal signature.asc Description: Digital signature
Re: HttpRequest.read() issues
Graham Dumpleton: Silly question. Where is the proof that using a limited stream is a performance issue? Last night I actually did test it :-). You're right the difference in performance is less than a statistical deviation between different uploads over network. Tom Christie: Even so, presumably we wouldn't want WSGIRequest to create a LimitedStream object for _every_ single incoming HTTP request, regardless of if it actually has a payload or not? In that case deferring the LimitedStream creation, but always ensuring that HttpRequest._stream is a LimitedStream rather than the underlying stream would be a sensible thing to do. And this one looks like another premature optimization :-). Creating a single wrapper object is a negligible hit but the code bloat from making it lazy is very real. So I'm -1 on laziness. #15785 - HttpRequest.read(NUM_BYTES) can read beyond the end of wsgi.input stream. There is a patch (with tests) attached. [2] Apart from the laziness issue your patch looks fine to me. Thanks! -- 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: HttpRequest.read() issues
> Last night I actually did test it :-). You're right the difference in > performance is less than a statistical deviation between different > uploads over network. Nice work. And point well made Graham! > Creating a single wrapper object is a negligible hit but the code bloat from making > it lazy is very real. So I'm -1 on laziness. > Apart from the laziness issue your patch looks fine to me. Thanks! Great stuff. New patch added to the ticket, just to keep everything easy. http://code.djangoproject.com/attachment/ticket/15785/limited_stream_lazy.diff Coolio, thanks for input peeps... t. -- 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] Composite fields: proposal draft 1, full version
On Thu, Apr 07, 2011 at 03:36:52PM +0800, Russell Keith-Magee wrote: > On Thu, Apr 7, 2011 at 2:51 AM, Michal Petrucha > wrote: > > GSoC 2011 Proposal: Composite Fields > > > > Hi Michal, > > This looks to be a fairly solid proposal. You've done a lot of > detailed research, and while I'm almost completely certain you'll find > some gremlin lurking underneath some dark corner of the code, you > appear to have a good grasp on the scope of the problem you're > proposing to solve. > > A couple of quick comments: > > > Relationship fields > > ~~~ > > > > This turns out to be, not too surprisingly, the toughest problem. The fact > > that related fields are spread across about fifteen different classes, > > most of which are quite nontrivial, makes the whole bundle pretty fragile, > > which means the changes have to be made carefully not to break anything. > > Feel free to do some housekeeping while you're in there :-) The > internal structure of foreign keys and m2ms isn't officially stable > API, so you have some liberty to do some cleanup. There will certainly have to be some changes but I'll try to keep them as small as possible. I already have enough on my plate, I think. (-: > > This infrastructure will allow reimplementing the GenericForeignKey as a > > CompositeField at a later stage. Thanks to the modifications in the > > joining code it should also be possible to implement bidirectional generic > > relationship traversal in QuerySet filters. This is, however, out of scope > > of this project. > > This, for me, is ultimately one of the biggest areas for gain. Adding > the new features of composite FKs and PKs will certainly be a big > benefit, cleaning up the special case handling for Generic Foreign > Keys will be a much bigger architectural win. > > I appreciate that you have to draw the line somewhere; but I suspect > that you may be faced with the need to modify an interface in a way > that will make it easier to handle CompositeFields, but breaks the > existing implementation of Generic Keys. If this happens, updating > GenericKeys may be an inevitable consequence. My intention is to generalize the interfaces trying to keep them backwards compatible where possible and modify them in a way that requires least updates on this end. I know this sounds awfully vague but most interfaces set up to support GFKs are already capable of doing the tasks required by CompositeFields. > > As I will have quite a few exams at school throughout June, I won't be > > able to commit myself fully to the project for the first month and will > > spend approximately 20 hours per week during this period. By the end of > > the exam period, however, I intend to have sped up to about 30-35 hours > > per week. > > I don't have any problem with this; it's an unfortunate consequence of > European school terms. However, we've historically encouraged > applicants to stretch the rules a little bit, and start early on their > project so they can compensate for at least some of the time they lose > during exams. I'll try to find some time and begin earlier but there are a couple of school project I will have to have finished by the end of the semester which is May 13, and these will also require some time. In the end I will probably only get a week's head start at most... > > week 5 (Jun 20. - Jun 26.): > > - ModelForms and GFK support for composite primary keys > > > > week 6 (Jun 27. - Jul 3.): > > - full support in the admin > > Weeks 5 and 6 seem particularly ambitious -- not completely > impossible, mind; just very ambitious. As I wrote in my reply to Jacob, I'll probably drop the GFK support which would make the fifth week lighter. As for the sixth week, a nontrivial part of the admin work is hidden in ModelForms. Maybe I'm overlooking something but most of the code should work as soon as the underlying forms and querysets support composite fields. > > week 7 (Jul 4. - Jul 10.): > > - fixing any documentation discrepancies and making sure everything is > > tested thoroughly > > - exploring the related fields in detail and working up a detailed plan > > for the following changes > > > > > midterm > > By the time midterm evaluation arrives, everything except for > > relationship fields should be in production-ready state. > > > > week 8 (Jul 11. - Jul 17.): > > - implementing composite primary key support in all the > > RelatedObjectDescriptors > > > > week 9 (Jul 18. - Jul 24.): > > - query joins refactoring > > - support for ForeignKey relationship traversals > > Again -- another ambitious week. Maybe I should split this into two weeks and leave only one week to finalize? > > week 10 (Jul 25. - Jul 31.): > > - making sure OneToOne and ManyToMany work as well > > > > weeks 11&12 (Aug 1. - Aug 14.): > > - writing even more tests for the relationships > > - finishing any missing documentation > > > > > pencils down > > > > As can be se
[GSoC] Py3K Support
My name is Martin Kunev. I am 21 years old. I am a Computer sciences student at Sofia university, Bulgaria. I have good knowledge of Python, PHP and C. I also have experience programming in C++, Java, JavaScript, Scheme, Haskell and bash. I am experienced in data structures and algorithms. I have written lots of client-server applications. I have worked as a web developer. Currently I am working at the hosting company WebConnect (http://webconnect.bg) as a programmer. One of my major tasks there is to maintain Django. I have also made changes to xend (which is written in Python), to make it suitable for our needs at webconnect. However I have a lot of free time. I think Python is a great language and I want to contribute its transition from version 2 to 3. I want to help porting Django to Python 3. -- 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.
Migrate Geodjango to Google Maps API v3
Hi. As in http://groups.google.com/group/geodjango/browse_thread/thread/a4e8d89fb355009b/7167f9bef1b4e546?lnk=gst&q=v3#7167f9bef1b4e546 I saw some moves into migrating to Google Maps API v3, mostly because it will be deprecated soon. I started to work on it because this new version have some features I need. So, using the patch at http://code.djangoproject.com/ticket/14284 as a starting point I grow it to something usable at http://github.com/alanjds/django/tree/gis_gmaps_v3 . Now, as far as I tested, it is working good for the things old code already does for v2, and I'm adding features new to v3, as streetview. Is there a chance to get this into the main tree? Is there something I need to change to allow it to be done? Thanks in advance, Alan. -- 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.
[GSoC2011] Integrate databrowse into admin
Hello everyone. My name is Stefan, and I'm a 19 years old student in
Iasi, Romania, at Faculty of
Computer Science. I've started programming as a young kid (I was about 8
or 9) and
have been programming since then. I've started with the silly mIRC
scripting and Visual
Basic and then moved on to various real programming languages (e.g. C,
C++, Python,
Javascript, PHP, C# etc.) and various projects (mostly as a freelancer
and on personal projects).
This is my second time to participate on GSoC (I also participated last
year for Boost) and I
would really like to have the chance to work on a major project again.
I would like to work on removing databrowse from django and implement
its features on admin.
Although I have worked plenty with Python and other MVC frameworks
(mostly PHP ones), I
haven't started learning django until recently. I've read some of
databrowse's source code and toyed
with it a little and I realize it's pretty limited in functionality and,
as has been said, has multiple unfixed
bugs and lacks maintenance. It is too limited to be used for any
production purposes,
and admin does a pretty good job for both production and dev phases.
A few important features of databrowse include read-only access to
tables and rows, filtering by possible values
of a field (such as filtering by calendar date for datetime fields or
filtering by any of the values that match for
at least one row) and automatically displaying one-to-many,many-to-one
and many-to-many relationships
between models. Looking through the source-code, I realize that not even
the obvious problems have been fixed:
For instance, when creating hyperlinks to objects,
datastructures.EasyInstanceField.urls attempts to call
_get_pk_call() on values returned by
datastructures.EasyInstanceField.values(), which might return
strings or even NoneType (this occurs, for instance, when you have a
null foreign key, which is normal
if you would like to, for example, store a rooted tree). The patch is
trivial, and I've attached it here.
That said, I would like to merge its functionality into admin. Users
will have separate permissions
for viewing (which will be granted implicitly with change/delete, it
doesn't make much sense to be able to
change/delete without viewing in a web app). There will be multiple ways
of viewing the data, one that
lists all the tables and their relationships, allowing to view all rows
in a table (with the now-lacking pagination)
and the rows related to it (via foreign keys), with the possibility of
filtering by each of the fields. Another way
of viewing the rows are in a tree-view, in which all rows that are
subordinated (via a foreign key) to other
rows will appear underneath and indented to the right of the parent row.
The rows can be either displayed
by their representation (__unicode__) or by some kind of table showing
all of their fields. Pagination will
be added here too. Rows whose all foreign keys are null will appear as
roots, and so will the rows who
don't have foreign keys (i.e. belong to a table w/ no foreign keys). All
others should appear as children
of at least one row (can appear as children to multiple rows in case the
relationships are many-to-many).
This data viewing interfaces will have means of adding, changing or
deleting rows, which will forward
to the admin interface. If, for instance, one clicks something like "add
child" on a row whose primary
key field is the foreign key of another table, then a row of that table
will be created, whose foreign
key will be set to this row's primary key.
I apologize for being so late with the proposal, I really wish I could
have written it earlier.
I'm planning on writing a timeline for the final version of the
proposal, but please let me know what
your opinion is first.
Yours faithfully,
Stefan M.
--
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.
--- D:/tmp/django-trunk/django/contrib/databrowse/datastructures.py Thu Apr
07 23:11:16 2011
+++ D:/python27/Lib/site-packages/django/contrib/databrowse/datastructures.py
Thu Apr 07 23:15:37 2011
@@ -9,6 +9,7 @@
from django.utils.encoding import smart_unicode, smart_str, iri_to_uri
from django.utils.safestring import mark_safe
from django.db.models.query import QuerySet
+from exceptions import AttributeError
EMPTY_VALUE = '(None)'
DISPLAY_SIZE = 100
@@ -184,7 +185,10 @@
if self.field.rel.to in self.model.model_list:
lst = []
for value in self.values():
-url = mark_safe('%s%s/%s/objects/%s/' %
(self.model.site.root_url, m.model._meta.app_label, m.model._meta.module_name,
iri_to_uri(value.
Re: [GSoC] Revised form rendering
I finally submitted my proposal to the google melange homepage. The core of the proposal is very much unchanged to the first draft, however I've included passages that indicate that the syntax might change in further discussions about this topic and that the concept of a chrome will be propably dropped in favour of more flexible template based widgets -- I didn't wanted to include a new detailed view on this topic without knowing how the final implementation for template based widgets will look like. For all that are interested, here are some links with more information about my submission: 1. The official submission on the google-melange.com homepage: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/gregmuellegger/1 2. The latest revision (and its change history) of the proposal on github (maybe also nicer formated): https://gist.github.com/898375 I will get back to the list kicking of some more discussions about the syntax next week and doing some syntax "testing" like we previously discussed in this thread. Gregor -- 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] Py3K Support
On Thu, Apr 7, 2011 at 5:20 PM, martinkunev wrote: > My name is Martin Kunev. I am 21 years old. I am a Computer sciences > student at Sofia university, Bulgaria. > > I have good knowledge of Python, PHP and C. I also have experience > programming in C++, Java, JavaScript, Scheme, Haskell and bash. I am > experienced in data structures and algorithms. > > I have written lots of client-server applications. I have worked as a > web developer. Currently I am working at the hosting company > WebConnect (http://webconnect.bg) as a programmer. One of my major > tasks there is to maintain Django. I have also made changes to xend > (which is written in Python), to make it suitable for our needs at > webconnect. However I have a lot of free time. > > I think Python is a great language and I want to contribute its > transition from version 2 to 3. I want to help porting Django to > Python 3. > > -- > 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. > > Hi Martin, We're glad you're interested in Google Summer of Code. Python 3 is a topic I'm personally very interested, however usually we expect a much higher level of detail from GSOC proposals, you need to prove to use you've done your research and know what all the issues are; take a look at some of the other GSOC proposals to get an idea of the level of detail we're looking for. Thanks, Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -- 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 2011: Less than 24 hours to submit your proposal on Melange
Hello potential GSoC students, There's now less than 24 hours before the deadline closes for GSoC - it closes at 19:00 UTC on April 8th (that's around 20 hours from when this post was sent). If you've got a proposal that isn't in google-melange yet, please register and add it; you're allowed to update the submitted proposal right up until the deadline, so it doesn't need to be perfect on the initial submission. If you don't submit your proposal in time, you'll be unable to take part in this year's GSoC. Happy proposal-writing. Andrew -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: [GSoC] Composite fields: proposal draft 2
I tried to incorporate the remarks into my proposal and I'm posting the updated parts. As usual, the full version is still available at http://people.ksp.sk/~johnny64/GSoC-full-proposal Retrieval and assignment Jacob has actually already provided a skeleton of the code that takes care of this as seen in [1]. I'll only summarize the behaviour in a brief example of my own. class SomeModel(models.Model): first_field = models.IntegerField() second_field = models.CharField(max_length=100) composite = models.CompositeField(first_field, second_field) >>> instance = new SomeModel(first_field=47, second_field="some string") >>> instance.composite CompositeObject(first_field=47, second_field='some string') >>> instance.composite.first_field 47 >>> instance.composite[1] 'some string' >>> instance.composite = (74, "other string") >>> instance.first_field, instance.second_field (74, 'other string') Accessing the field attribute will create a CompositeObject instance which will behave like a tuple but also with direct access to enclosed field values via appropriately named attributes. Assignment will be possible using any iterable. The order of the values in the iterable will have to be the same as the order in which undelying fields have been specified to the CompositeField. QuerySet filtering ~~ [...] Afterwards the handling inside Query is pretty straightforward. For CompositeFields (and virtual fields in general) there is no value to be used in the where node, the extra_filters are responsible for all filtering, but since the filter should apply to a single object even after join traversals, the aliases will be set up while handling the "root" filter and then reused for each one of the extra_filters. This way of extending the extra_filters mechanism will allow the field class to create conjunctions of atomic conditions. This is sufficient for the "__exact" lookup type which will be implemented. Of the other lookup types, the only one that looks reasonable is "__in". This will, however, have to be represented as a disjunction of multiple "__exact" conditions since not all database backends support tuple construction inside expressions. Therefore this lookup type will be left out of this project as the mechanism would need much more work to make it possible. GenericForeignKeys ~~ Even though the admin uses the contenttypes framework to log the history of actions, it turns out proper handling on the admin side will make things work without the need to modify GenericForeignKey code at all. This is thanks to the fact that the admin uses only the ContentType field and handles the relations on its own. Making sure the unquoting function recreates the whole CompositeObjects where necessary should suffice. At a later stage, however, GenericForeignKeys could also be improved to support composite primary keys. Using the same quoting solution as in the admin could work in theory, although it would only allow fields capable of storing arbitrary strings to be usable for object_id storage. This has been left out of the scope of this project, though. Estimates and timeline -- The proposed timeline is as follows: week 1 (May 23. - May 29.): - basic CompositeField implementation with assignment and retrieval - documentation for the new field type API week 2 (May 30. - Jun 5.): - creation of indexes on the database - unique conditions checking regression tests week 3 (Jun 6. - Jun 12.): - query code refactoring to make it possible to support the required extra_filters - lookups by CompositeFields week 4 (Jun 13. - Jun 19.): - creation of a composite primary key - more tests and taking care of any missing/forgotten documentation so far week 5 (Jun 20. - Jun 26.): - ModelForms support for composite primary keys week 6 (Jun 27. - Jul 3.): - full support in the admin week 7 (Jul 4. - Jul 10.): - fixing any documentation discrepancies and making sure everything is tested thoroughly - exploring the related fields in detail and working up a detailed plan for the following changes > midterm By the time midterm evaluation arrives, everything except for relationship fields should be in production-ready state. week 8 (Jul 11. - Jul 17.): - implementing composite primary key support in all the RelatedObjectDescriptors week 9 (Jul 18. - Jul 24.): - query joins refactoring week 10 (Jul 25. - Jul 31.): - support for ForeignKey relationship traversals week 11 (Aug 1. - Aug 7.): - making sure OneToOne and ManyToMany work as well week 12 (Aug 8. - Aug 14.): - writing even more tests for the relationships - finishing any missing documentation > pencils down signature.asc Description: Digital signature
Re: [GSoC2011] Integrate databrowse into admin
On Fri, Apr 8, 2011 at 5:37 AM, M Stefan wrote: > Hello everyone. My name is Stefan, and I'm a 19 years old student in Iasi, > Romania, at Faculty of > Computer Science. I've started programming as a young kid (I was about 8 or > 9) and > have been programming since then. I've started with the silly mIRC scripting > and Visual > Basic and then moved on to various real programming languages (e.g. C, C++, > Python, > Javascript, PHP, C# etc.) and various projects (mostly as a freelancer and > on personal projects). > This is my second time to participate on GSoC (I also participated last year > for Boost) and I > would really like to have the chance to work on a major project again. > > I would like to work on removing databrowse from django and implement its > features on admin. > Although I have worked plenty with Python and other MVC frameworks (mostly > PHP ones), I > haven't started learning django until recently. I've read some of > databrowse's source code and toyed > with it a little and I realize it's pretty limited in functionality and, as > has been said, has multiple unfixed > bugs and lacks maintenance. It is too limited to be used for any production > purposes, > and admin does a pretty good job for both production and dev phases. In fairness, it's not really intended for "production" -- it's a data exploration tool. It's also a tool that hasn't seen a lot of work since it was initially added; hence the motivation to merge it with admin. > A few important features of databrowse include read-only access to tables > and rows, filtering by possible values > of a field (such as filtering by calendar date for datetime fields or > filtering by any of the values that match for > at least one row) and automatically displaying one-to-many,many-to-one and > many-to-many relationships > between models. Looking through the source-code, I realize that not even the > obvious problems have been fixed: > For instance, when creating hyperlinks to objects, > datastructures.EasyInstanceField.urls attempts to call > _get_pk_call() on values returned by > datastructures.EasyInstanceField.values(), which might return > strings or even NoneType (this occurs, for instance, when you have a null > foreign key, which is normal > if you would like to, for example, store a rooted tree). The patch is > trivial, and I've attached it here. If you've found a patch for a specific bug, then you should open a ticket and attach your patch there. > That said, I would like to merge its functionality into admin. Users will > have separate permissions > for viewing (which will be granted implicitly with change/delete, it doesn't > make much sense to be able to > change/delete without viewing in a web app). There will be multiple ways of > viewing the data, one that > lists all the tables and their relationships, allowing to view all rows in a > table (with the now-lacking pagination) > and the rows related to it (via foreign keys), with the possibility of > filtering by each of the fields. Another way > of viewing the rows are in a tree-view, in which all rows that are > subordinated (via a foreign key) to other > rows will appear underneath and indented to the right of the parent row. The > rows can be either displayed > by their representation (__unicode__) or by some kind of table showing all > of their fields. Pagination will > be added here too. Rows whose all foreign keys are null will appear as > roots, and so will the rows who > don't have foreign keys (i.e. belong to a table w/ no foreign keys). All > others should appear as children > of at least one row (can appear as children to multiple rows in case the > relationships are many-to-many). > This data viewing interfaces will have means of adding, changing or deleting > rows, which will forward > to the admin interface. If, for instance, one clicks something like "add > child" on a row whose primary > key field is the foreign key of another table, then a row of that table will > be created, whose foreign > key will be set to this row's primary key. > > I apologize for being so late with the proposal, I really wish I could have > written it earlier. > I'm planning on writing a timeline for the final version of the proposal, > but please let me know what > your opinion is first. Well -- to be brutally honest: From a high level, the project is interesting, and you appear to be roughly on the right track. However, so far, your proposal is a fairly light elaboration of what Django's GSoC wiki already gives you, and that's a long way from being an proposal that is likely to be accepted. You're proposing a set of fairly major modifications to admin, and all we have to go on is a paragraph of loose descriptions of what you intend to do. Time is running out for GSoC applications; if you want your proposal to be taken seriously, you need to provide a lot more elaboration and a timeline -- and quickly. Yours, Russ Magee %-) -- You received this message because you are subscri
GSoc : Templates Compilation , draft 2
Hello,
I'm Andrey Zubko, student faculty of Computer Science in Zaporozhye
State Engineering Academy. I'm senior chief developer of a local
Internet Service Provider "Telza" which provides Internet and
telephony services. My responsibilities includes enhancing, improving
existent Billing system that is written by myself.
In GSOC program I want to improve template subsystem by integrating
template compilation into python bytecode.
Goals and challenges
Integrating of template compilation has 2 goals. The first goal and
the chief goal is to provide backward-compatibility to templates,
custom tags, custom filters that are already written. The second
goal is to minimize modifications of Django sources to provide more
stability and faster integrating in trunk.
Implementation
Support of template compilation can be achieved by adding method
'compile' to every Node-derived class, and some other classes,
functions, such as django.template.Variable,
django.template.FilterExpression, django.template.NodeList, and others
described further.
1. Node and Node-derived classes modifications
Class Node and derived from it classes should have optional method –
compile, it returns list of python bytecode commands for write in
compiled template. It receives parameter parent_name that will
contains name of uppermost tag/block. Parent_name is a name of
uppermost tag/block that identifies entry in hash blocks_output that
is used for caching all outputs. Only one case can provide parent_name
to be overridden – meet of the '{% block %}' tag in a parent tag, this
tag should override parent_name to its unique name. Approach for
caching all output is used for providing template inheritance ability.
Use of template Inheritance provides following cases :
child template has one sequence of blocks, but parent template has
another sequence of blocks
child template has blocks that haven't specified in parent's template
For solving this cases I provided list blocks_sequence_output that
keeps sequence of blocks outputting. Implementation of 'compile'
method in Node class :
def compile(self,parent_name):
self.generate_name(parent_name)
compiled_code = ["t = Template('%s')" % self.template,
"blocks_output['%s'] = blocks_output['%s'] +
t._render(context)" % (self.parent_name,self.parent_name)]
return compiled_code
As you saw, in purposes of providing backward-compatibility all Node-
derived classes, that haven't implemented 'compile' method, will use
current rendering approach.
Node-derived classes with implemented 'compile' method will be looked
like :
class TextNode(Node):
def compile(self,parent_name):
return ["blocks_output['%s'] = blocks_output['%s'] + \"\"\"%s
\"\"\"" % (self.parent_name,
self.parent_name,
self.s)]
As shown before 'compile' method is not so difficult to implement.
To recursively compilation of Node-derived classes is used method
'compile' in the class NodeList :
class NodeList(list):
def generate_name(self,node):
return id(node)
def compile(self, parent_name=None):
bits = []
for node in self:
if isinstance(node, Node):
if parent_name is None or isinstance(node,
BlockNode) :
if isinstance(node, BlockNode) :
parent_name_new = node.name
else :
parent_name_new = self.generate_name(node)
bits.append("blocks_output['%s']=''" %
parent_name_new)
else :
parent_name_new = parent_name
bits.append(self.compile_node(node, parent_name_new))
else:
bits.append(node)
return mark_safe(''.join([force_unicode(b) for b in bits]))
Also this function is used for initialising blocks_output hashes for
uppermost nodes.
2. Blocks and dynamical inheritance
I have described before Node-derived classes improvements, but
django.template.loader_tags.BlockNode, django.template.loader_tags,
django.template.loader_tages.ExtendsNode and others have big influence
on compiled template architecture design, that's why I have allocated
whole section for them. Internal variables blocks_output,
blocks_output_sequence are used for providing support of dynamic
inheritance. They specify the way how template should be rendered, in
what sequence, what blocks should be outputted to user.
'blocks_output' hash collects blocks or tags outputs, and
blocks_output_sequence saves sequence of block outputting. Because
parent template can contain its own sequence of blocks that is saved
in blocks_output_sequence, we must update the child
blocks_output_sequence without right of overriding it. Because parent
template can contain own blocks that is not present in child template,
we must update child blocks_output hash with not existing items in it.
By solving this requirements class BlockNode will be looked like :
class BlockNode(Node):
Re: GSoc : Templates Compilation , draft 2
On Fri, Apr 8, 2011 at 9:15 AM, Andrey Zubko wrote:
> Hello,
> I'm Andrey Zubko, student faculty of Computer Science in Zaporozhye
> State Engineering Academy. I'm senior chief developer of a local
> Internet Service Provider "Telza" which provides Internet and
> telephony services. My responsibilities includes enhancing, improving
> existent Billing system that is written by myself.
>
> In GSOC program I want to improve template subsystem by integrating
> template compilation into python bytecode.
>
> Goals and challenges
> Integrating of template compilation has 2 goals. The first goal and
> the chief goal is to provide backward-compatibility to templates,
> custom tags, custom filters that are already written. The second
> goal is to minimize modifications of Django sources to provide more
> stability and faster integrating in trunk.
> Implementation
> Support of template compilation can be achieved by adding method
> 'compile' to every Node-derived class, and some other classes,
> functions, such as django.template.Variable,
> django.template.FilterExpression, django.template.NodeList, and others
> described further.
>
> 1. Node and Node-derived classes modifications
> Class Node and derived from it classes should have optional method –
> compile, it returns list of python bytecode commands for write in
> compiled template. It receives parameter parent_name that will
> contains name of uppermost tag/block. Parent_name is a name of
> uppermost tag/block that identifies entry in hash blocks_output that
> is used for caching all outputs. Only one case can provide parent_name
> to be overridden – meet of the '{% block %}' tag in a parent tag, this
> tag should override parent_name to its unique name. Approach for
> caching all output is used for providing template inheritance ability.
> Use of template Inheritance provides following cases :
> child template has one sequence of blocks, but parent template has
> another sequence of blocks
> child template has blocks that haven't specified in parent's template
>
> For solving this cases I provided list blocks_sequence_output that
> keeps sequence of blocks outputting. Implementation of 'compile'
> method in Node class :
> def compile(self,parent_name):
> self.generate_name(parent_name)
> compiled_code = ["t = Template('%s')" % self.template,
> "blocks_output['%s'] = blocks_output['%s'] +
> t._render(context)" % (self.parent_name,self.parent_name)]
> return compiled_code
>
> As you saw, in purposes of providing backward-compatibility all Node-
> derived classes, that haven't implemented 'compile' method, will use
> current rendering approach.
> Node-derived classes with implemented 'compile' method will be looked
> like :
> class TextNode(Node):
> def compile(self,parent_name):
> return ["blocks_output['%s'] = blocks_output['%s'] + \"\"\"%s
> \"\"\"" % (self.parent_name,
>
> self.parent_name,
>
> self.s)]
>
> As shown before 'compile' method is not so difficult to implement.
> To recursively compilation of Node-derived classes is used method
> 'compile' in the class NodeList :
> class NodeList(list):
> def generate_name(self,node):
> return id(node)
>
> def compile(self, parent_name=None):
> bits = []
> for node in self:
> if isinstance(node, Node):
> if parent_name is None or isinstance(node,
> BlockNode) :
> if isinstance(node, BlockNode) :
> parent_name_new = node.name
> else :
> parent_name_new = self.generate_name(node)
>
> bits.append("blocks_output['%s']=''" %
> parent_name_new)
> else :
> parent_name_new = parent_name
>
> bits.append(self.compile_node(node, parent_name_new))
> else:
> bits.append(node)
> return mark_safe(''.join([force_unicode(b) for b in bits]))
>
> Also this function is used for initialising blocks_output hashes for
> uppermost nodes.
>
> 2. Blocks and dynamical inheritance
> I have described before Node-derived classes improvements, but
> django.template.loader_tags.BlockNode, django.template.loader_tags,
> django.template.loader_tages.ExtendsNode and others have big influence
> on compiled template architecture design, that's why I have allocated
> whole section for them. Internal variables blocks_output,
> blocks_output_sequence are used for providing support of dynamic
> inheritance. They specify the way how template should be rendered, in
> what sequence, what blocks should be outputted to user.
> 'blocks_output' hash collects blocks or tags outputs, and
> blocks_output_sequence saves sequence of block outputting. Because
> parent template can contain its own sequence of blocks that is saved
> in blocks_output_sequence, we must update the child
> blocks_output_sequence without right of overriding it. Because parent
> template ca
