Re: Direction on #10899
On Tuesday, 26 October 2010 at 01:24, Preston Timmons wrote: Hi,Could one of the core devs take a look over #10899 and give someguidance on what the best step to take next is? Thanks.I'm not a core dev, but it looks like the patch is missing documentation and the code needs a review by somebody other than the original author.Dougal -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
#4992: Cache GET requests with QUERY_STRING
Hi, requests with a QUERY_STRING are not cached up to now. I uploaded a patch with tests and I think it is ready for commit: http://code.djangoproject.com/ticket/4992 According to http://docs.djangoproject.com/en/1.2/internals/contributing/#triage-by-the-general-community I (general community member) should not set "ready for commit". Could someone please review it? Thomas -- 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-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
CSV serializer?
I was wondering what the prospect was of getting a CSV serializer added to Django. It seems like it would be useful for many use cases, especially for bulk editing of objects by non-technical users. We have this requirement where I work, so I wrote a CSV serializer: http://djangosnippets.org/snippets/2240/. It would be nice to get something like this in Django. I see that there was some effort a while back in ticket #5253 (http://code.djangoproject.com/ticket/ 5253), but it looks like it has sort of died on the vine. I'd be happy to submit my code, but I don't want to step on any toes if something is already in progress. Would it be appropriate to open a new ticket? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
choosing queryset
I've two modules called plan and income and both have a class called Income in their respective models. Now if I do user.income_set, it is accessing the income set under plan. How do I alter it to access income.income? Any ideas? Thanks in advance -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
New localflavor: Turkey
Hello, I have created a new localflavor for Turkey and attached the sources and documentation to the ticket #14563 (http://code.djangoproject.com/ ticket/14563). Is it possible that this new local flavor could be added to 1.3 release? Best regards, Serkan Kenar -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: choosing queryset
> I've two modules called plan and income and both have a class called > Income in their respective models. Now if I do user.income_set, it is > accessing the income set under plan. How do I alter it to access > income.income? Any ideas? Please don't cross-post. Your question should go to django-users ONLY. Thank you Jirka -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: CSV serializer?
On Tue, Oct 26, 2010 at 12:01 PM, David Lindquist wrote: > I was wondering what the prospect was of getting a CSV serializer > added to Django. It seems like it would be useful for many use cases, > especially for bulk editing of objects by non-technical users. We have > this requirement where I work, so I wrote a CSV serializer: > http://djangosnippets.org/snippets/2240/. It would be nice to get > something like this in Django. I see that there was some effort a > while back in ticket #5253 (http://code.djangoproject.com/ticket/ > 5253), but it looks like it has sort of died on the vine. I'd be happy > to submit my code, but I don't want to step on any toes if something > is already in progress. Would it be appropriate to open a new ticket? A new ticket isn't required -- the feature request hasn't fundamentally changed. I'm also not aware of any work in progress in this area. The fundamental issue that hit the last CSV serializer effort was demonstrating that the serialization format that was being proposed was actually viable, and suffciently 'common' that it was appropriate for the core. Formats like JSON, XML, and YAML have a fundamentally agreed structure for representing complex data, and while Django's serializer uses a particular set of formatting conventions, the JSON data is parseable by any JSON compliant parser. CSV has a basic structure (i.e., comma separated values), but doesn't have a natural way of representing multiple datatypes, multiple values for a single field, or differentiating NULL from empty string. Even in-file metadata (sometimes represented as the first, commented out row of a CSV file) is the subject of inconsistency. For a serializer to land in trunk, it needs to be clear that the proposed serializer would produce output in a format that will be immediately and obviously useful by other consumers -- e.g., that Django-genereated CSV output would be useful (and meaningful) as input to Excel. So far, I haven't seen a proposed format that would meet this criterion. Instead of introducing a specific CSV serializer to Django, my preference would be to improve the serialization framework such that implementing a CSV serializer could be a relatively simple configuration exercise, rather than a major engineering effort. This is obviously a lot more work than just introducing a single new serializer, but I think it would ultimately yield a lot more useful outcomes -- not the least of which would be providing a way to get CSV-serialized output without needing to dictate a single output format. 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-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: New localflavor: Turkey
On Tue, Oct 26, 2010 at 7:46 PM, Serkan Kenar wrote: > Hello, > > I have created a new localflavor for Turkey and attached the sources > and documentation to the ticket #14563 (http://code.djangoproject.com/ > ticket/14563). Is it possible that this new local flavor could be > added to 1.3 release? It's certainly possible. However, the patch still needs a little work. Firstly, the patch doesn't contain any tests for the new functionality. Localflavors have historically been light on testing, but that is a trend we should be trying to break. Confirmation of the validation algorithms underlying the new form fields work as advertised would be an absolute minimum. Tests should be added to the tests/regressiontests/forms/localflavor directory; however, if you're adding new tests, please write them as unittests, rather than doctests. Secondly, all the work should be submitted in a single patch, not multiple patches. Documentation, tests and new feature code should all be contained in a single patch file. Thirdly, the patch needs verification by a third party, preferably someone familiar with Turkish data entry requirements. This doesn't need to be anyone special or 'blessed' in the Django community - it just needs to be someone who isn't the patch author that is willing to provide an independent verification that the patch does what it says it should do. Thanks for the contribution -- if you add make these modifications, this is certainly something we can target for inclusion in 1.3. 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-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: CSV serializer?
On Oct 26, 8:05 am, Russell Keith-Magee wrote: > On Tue, Oct 26, 2010 at 12:01 PM, David Lindquist > > wrote: > > I was wondering what the prospect was of getting a CSV serializer > > added to Django. It seems like it would be useful for many use cases, > > especially for bulk editing of objects by non-technical users. We have > > this requirement where I work, so I wrote a CSV serializer: > >http://djangosnippets.org/snippets/2240/. It would be nice to get > > something like this in Django. I see that there was some effort a > > while back in ticket #5253 (http://code.djangoproject.com/ticket/ > > 5253), but it looks like it has sort of died on the vine. I'd be happy > > to submit my code, but I don't want to step on any toes if something > > is already in progress. Would it be appropriate to open a new ticket? > > A new ticket isn't required -- the feature request hasn't > fundamentally changed. I'm also not aware of any work in progress in > this area. > > The fundamental issue that hit the last CSV serializer effort was > demonstrating that the serialization format that was being proposed > was actually viable, and suffciently 'common' that it was appropriate > for the core. Formats like JSON, XML, and YAML have a fundamentally > agreed structure for representing complex data, and while Django's > serializer uses a particular set of formatting conventions, the JSON > data is parseable by any JSON compliant parser. CSV has a basic > structure (i.e., comma separated values), but doesn't have a natural > way of representing multiple datatypes, multiple values for a single > field, or differentiating NULL from empty string. Even in-file > metadata (sometimes represented as the first, commented out row of a > CSV file) is the subject of inconsistency. > > For a serializer to land in trunk, it needs to be clear that the > proposed serializer would produce output in a format that will be > immediately and obviously useful by other consumers -- e.g., that > Django-genereated CSV output would be useful (and meaningful) as input > to Excel. So far, I haven't seen a proposed format that would meet > this criterion. > > Instead of introducing a specific CSV serializer to Django, my > preference would be to improve the serialization framework such that > implementing a CSV serializer could be a relatively simple > configuration exercise, rather than a major engineering effort. This > is obviously a lot more work than just introducing a single new > serializer, but I think it would ultimately yield a lot more useful > outcomes -- not the least of which would be providing a way to get > CSV-serialized output without needing to dictate a single output > format. > > Yours, > Russ Magee %-) Thanks Russ for your detailed, well-reasoned response. What you said about CSV having a basic structure but inconsistencies in other areas is something I ran up against when I started investigating this. Sounds like a general solution is still a ways off. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: It is real to add ticket #8054 to 1.3 milestone?
Can anybody rewiew the patch? On Wed, Oct 13, 2010 at 6:35 PM, Alex Kamedov wrote: > Hi All, > > I uploaded patch with tests and little improvements > > http://code.djangoproject.com/attachment/ticket/8054/8054-list-column.5.diff > I think it ready for review. > > I really sorry, but I couldn't write good documentation because English > isn't my own language. The maximum of my possibility in writing docs is > here http://code.djangoproject.com/wiki/ListColumns For more examples > see folder admin_listcolumn in regression tests provided by last my patch. > > Cheers, > > Alex Kamedov > > On Wed, Oct 13, 2010 at 2:12 AM, Gabriel Hurley wrote: > >> Hi alekam, >> >> This is certainly the kind of ticket that we want to deal with in 1.3 >> since it's been around so long and deferred a couple times. Starting >> the discussion here is definitely the right way to make it happen. >> >> That said, at the very least it needs a thorough code review, a full >> set of tests, and good documentation before it can be included. >> >> I'm not personally sold on the way the functionality is implemented, >> but I'd have to think on what would be preferable. I'm sure others >> will have stronger opinions on it one way or the other. >> >> All the best, >> >>- Gabriel >> >> On Oct 12, 9:47 am, alekam wrote: >> > Hi All, >> > >> > I found very useful ticket #8054. This ticket has accepted status and >> > assigned to brosher about 2 years. The problem describes on ticket >> > detail page and in the wikihttp:// >> code.djangoproject.com/wiki/ListColumns >> > The ticket has patch witch passes all existing regression tests and I >> > plan to write unit tests for it. >> > It is real to add ticket #8054 to 1.3 milestone? >> > >> > Cheers, >> > >> > Alex Kamedov >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To post to this group, send email to django-develop...@googlegroups.com. >> To unsubscribe from this group, send email to >> django-developers+unsubscr...@googlegroups.com >> . >> For more options, visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> >> > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #7817: Extending "with" and "include" tags.
2010/6/30 Łukasz Rekucki : > Hi, > > I was wondering if I could get some feedback on this ticket. It was > recently briefly discussed here: > http://groups.google.com/group/django-developers/browse_thread/thread/fb8a4a0eb4e1d35e. > It has a patch with tests and probably not-so-good docs, but still > needs a decision. > > I'll gladly reviews some tickets or do any other volunteer labor in > exchange for someone to take a look at this ;) > > Best regards, > Lucas Rekucki > I would like to bring this up again, because this is something that would really improve readability of my templates. I'm mainly interested in ticket #7817 (the include tag changes), but extending "with" tag (ticket 9456) would keep things consistent. Best regards, Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: CSV serializer?
We have a CSV view (not a serializer) that is linked from every change_list page. This allows sufficiently privileged users to dump the database table into Excel to do things not covered by our existing views. We do not allow for a CSV import, but it's been something that we've wanted. We'd be very interested in this project. On Tue, 2010-10-26 at 23:05 +0800, Russell Keith-Magee wrote: > CSV has a basic > structure (i.e., comma separated values), but doesn't have a natural > way of representing multiple datatypes I think this is the biggest challenge. Could we come up with some criteria that would have to be met for a given field type's representation? Perhaps: 1) The field has to load correctly in Excel. 2) The field has to load correctly in OpenOffice.org. 3) The field has to be human readable, except where doing so would violate #1 or #2. 4) The field should match its most common SQL representation, except where doing so would violate #1, #2, or #3. Handling foreign keys is problematic. If you just export the key, you often end up with an integer that's meaningless. If you export the related object, do you use it's __unicode__ or something else? On import, do you match the provided values to existing values in the JOIN table or can new ones be added? To be honest, I haven't looked at the JSON serializer, so I'm not sure how this is handled there. Of course, JSON would support nested objects where CSV wouldn't. > multiple values for a single field When would this matter? Is there a field type in Django that uses SQL arrays? If not, SQL has the same issue. > or differentiating NULL from empty string Neither does CharField, so why does this matter? > Even in-file > metadata (sometimes represented as the first, commented out row of a > CSV file) is the subject of inconsistency. On export, you either have it or you don't. It seems that having a header row is better than not, so include it. This meets your "useful in Excel" criteria. As far as import, it's easy to strip the first row or not, but the big question is if you want to make it *optional*. If the goal of the serializer is to import data that you've previously export, then there's no need to make it optional. If you want something more generally useful, you'll have to look at the first row and try to match the columns to field names. If they all match, then it's a header row, if they don't, it's not. Richard signature.asc Description: This is a digitally signed message part
Permission support for admin inlines
The ModelAdmin's permission hooks are great- has_add_permission, has_change_permission, and has_delete_permission. It would be nice if they were supported by inlines in the same way; ie InlineModelAdmin, StackedInline, TabularInline, GenericStackedInline, GenericTabularInline. UI is fairly obvious; has_add would result in no add form; has_delete in no delete tick box; and for has_change, showing as readonly_fields would probably be easiest. Any thoughts? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Permission support for admin inlines
On 27 October 2010 08:15, Simon Litchfield wrote: > The ModelAdmin's permission hooks are great- has_add_permission, > has_change_permission, and has_delete_permission. > > It would be nice if they were supported by inlines in the same way; ie > InlineModelAdmin, StackedInline, TabularInline, GenericStackedInline, > GenericTabularInline. > > UI is fairly obvious; has_add would result in no add form; has_delete > in no delete tick box; and for has_change, showing as readonly_fields > would probably be easiest. > > Any thoughts? > > This should be considered together with the question of whether the user's general permissions should apply to inlines [1], which is in DDN at present. [1] http://code.djangoproject.com/ticket/8060 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Django on Google App Engine via SQL (not nonrel)
Dear Django developers, I got in touch with Jacob who suggested I contact you all together. As you may (or may not) know, at Google I/O back in May, we announced a hosted cloud SQL service as a new feature for our App Engine application cloud-hosting platform: http://code.google.com/appengine/business/#features http://googlecode.blogspot.com/2010/05/announcing-google-app-engine-for.html Our offering is mature enough now that we are exploring the final APIs that we’d like to ship as part of the App Engine Python SDK. As such, we’re exploring what’s required to enable the Django to use our MySQL-compatible library, thus providing ORM access to the App Engine datastore. We’re writing you at this time to get a sense of the effort that would be required to make this happen. We are excited about this new feature and would love to have some community involvement to get Django on-board as an option for users! Best regards, -Wesley Chun, Guido van Rossum, and Sean Lynch, Google App Engine team - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - "Core Python Programming", Prentice Hall, (c)2007,2001 "Python Fundamentals", Prentice Hall, (c)2009 http://corepython.com wesley.chun : wesc+api at google.com : @wescpy developer relations :: google app engine @app_engine :: googleappengine.blogspot.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django on Google App Engine via SQL (not nonrel)
On Tue, Oct 26, 2010 at 6:56 PM, wesley chun wrote: > Dear Django developers, > > I got in touch with Jacob who suggested I contact you all together. As > you may (or may not) know, at Google I/O back in May, we announced a > hosted cloud SQL service as a new feature for our App Engine > application cloud-hosting platform: > > http://code.google.com/appengine/business/#features > http://googlecode.blogspot.com/2010/05/announcing-google-app-engine-for.html > > Our offering is mature enough now that we are exploring the final APIs > that we’d like to ship as part of the App Engine Python SDK. As such, > we’re exploring what’s required to enable the Django to use our > MySQL-compatible library, thus providing ORM access to the App Engine > datastore. We’re writing you at this time to get a sense of the effort > that would be required to make this happen. We are excited about this > new feature and would love to have some community involvement to get > Django on-board as an option for users! > > Best regards, > -Wesley Chun, Guido van Rossum, and Sean Lynch, Google App Engine team > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > "Core Python Programming", Prentice Hall, (c)2007,2001 > "Python Fundamentals", Prentice Hall, (c)2009 > http://corepython.com > > wesley.chun : wesc+api at google.com : @wescpy > developer relations :: google app engine > @app_engine :: googleappengine.blogspot.com > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > It depends what you mean by "MySQL" compatible. If by that you mean that it's importable as mysqldb and implements the exact API it should work out of the box, more or less. However, if by that you mean it implements PEP-249 you really need to ship a database backend for Django (you probably want to do this anyway, I'll explain). Since this is SQL backend this isn't quiet so much work. Database backends basically consist of 2 things: a compiler, which is the core of the SQL generation, and "the rest of it" which is a series of flags and methods which make very small scale decisions about what features are available and how certain constructs are translated into SQL. The good thing is, assuming you've implemented SQL in something close to the standard (or any of the other DBs we support), the compiler will work more or less out of the box, and all you have to do is fill in the methods/flags on the backend for it to work, you can look to the external MSSQL, Sybase, or DB2 backend to see how this works. Of course if you support only a subset of SQL you'll probably need to override the compiler to either work around this (e.g. JOIN emulation) or raise an appropriate error. The links you provided don't give a ton of info about the exact nature of the SQL support (and I was fairly ignorant about it going in), but hopefully that helps and we can continue to help with more specific questions, Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django on Google App Engine via SQL (not nonrel)
On Wed, Oct 27, 2010 at 6:56 AM, wesley chun wrote: > Dear Django developers, > > I got in touch with Jacob who suggested I contact you all together. As > you may (or may not) know, at Google I/O back in May, we announced a > hosted cloud SQL service as a new feature for our App Engine > application cloud-hosting platform: > > http://code.google.com/appengine/business/#features > http://googlecode.blogspot.com/2010/05/announcing-google-app-engine-for.html > > Our offering is mature enough now that we are exploring the final APIs > that we’d like to ship as part of the App Engine Python SDK. As such, > we’re exploring what’s required to enable the Django to use our > MySQL-compatible library, thus providing ORM access to the App Engine > datastore. We’re writing you at this time to get a sense of the effort > that would be required to make this happen. We are excited about this > new feature and would love to have some community involvement to get > Django on-board as an option for users! Hi Wesley, Sounds exciting! It's difficult to judge the amount of effort that would be involved without knowing exactly how comprehensive the SQL-compatibility layer is. The best way to give us an idea of how much work needs to be done would be to run Django's test suite over your AppEngine SQL datastore. Django's database backends are fairly well abstracted representations of the eccentricities of SQL datastores, so if your MySQL emulation is reasonably complete, it should be possible to either use Django's MySQL backend, or adapt the MySQL backend into a custom 'AppEngine SQL' backend. Django allows (and encourages) the use of external backends, so shipping an external backend would be a natural way to provide AppEngine support. If it turns out that there are some additional interfaces needed on the backend in order to support the eccentricities of AppEngine, we're certainly open to introducing those interfaces. The window for committing new features is open right now (and will be till the end of November); if you can give an indication of the eccentricities that need to be accommodated (by giving us a list of test failures and an indication of why those tests are failing), we can look at the changes that we may need to make. 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-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: CSV serializer?
On Wed, Oct 27, 2010 at 3:57 AM, Richard Laager wrote: > We have a CSV view (not a serializer) that is linked from every > change_list page. This allows sufficiently privileged users to dump the > database table into Excel to do things not covered by our existing > views. We do not allow for a CSV import, but it's been something that > we've wanted. > > We'd be very interested in this project. > > On Tue, 2010-10-26 at 23:05 +0800, Russell Keith-Magee wrote: >> CSV has a basic >> structure (i.e., comma separated values), but doesn't have a natural >> way of representing multiple datatypes > > I think this is the biggest challenge. Could we come up with some > criteria that would have to be met for a given field type's > representation? > > Perhaps: > 1) The field has to load correctly in Excel. > 2) The field has to load correctly in OpenOffice.org. > 3) The field has to be human readable, except where doing so would > violate #1 or #2. > 4) The field should match its most common SQL representation, except > where doing so would violate #1, #2, or #3. > > Handling foreign keys is problematic. If you just export the key, you > often end up with an integer that's meaningless. If you export the > related object, do you use it's __unicode__ or something else? A natural key would be the obvious 'something else' here. Using the key value would be the approach most consistent with the other built-in serializers, with natural keys as a fallback under certain conditions. > On import, do you match the provided values to existing values in the > JOIN table or can new ones be added? > > To be honest, I haven't looked at the JSON serializer, so I'm not sure > how this is handled there. Of course, JSON would support nested objects > where CSV wouldn't. And yet, the JSON serializer doesn't *ever* nest objects. That's a long standing feature request, and yet another reason why I'm interested in a fully customizable serialization framework. >> multiple values for a single field > > When would this matter? Is there a field type in Django that uses SQL > arrays? If not, SQL has the same issue. Depends how you serialize m2m fields and natural keys. m2m fields can be 'faked' by serializing the m2m model as a collection of columns. This makes CSV serialization different to other serializers. This isn't a show-stopper, it's just worthy of note. Natural keys are a different story. You either need to expand a single column into multiple columns, or you need to have a parseable value in a single column. >> or differentiating NULL from empty string > > Neither does CharField, so why does this matter? There isn't a different for form entry (because there's no way for a user to form-submit "null", but there is a difference in the database, which is what the serializer is dealing with. The Oracle backend doesn't make the distinction between an empty string and NULL, but that's a peculiarity of Oracle. >> Even in-file >> metadata (sometimes represented as the first, commented out row of a >> CSV file) is the subject of inconsistency. > > On export, you either have it or you don't. It seems that having a > header row is better than not, so include it. This meets your "useful in > Excel" criteria. > > As far as import, it's easy to strip the first row or not, but the big > question is if you want to make it *optional*. > > If the goal of the serializer is to import data that you've previously > export, then there's no need to make it optional. If you want something > more generally useful, you'll have to look at the first row and try to > match the columns to field names. If they all match, then it's a header > row, if they don't, it's not. You've highlighted a bunch of design decisions that any single CSV serializer would need to make. The thing is, all the design issues you've highlighted here could go one way or the other, and the 'right' decision will vary wildly with circumstance. This is why I would rather see a general serialization framework, rather than a single CSV serializer. That way, rather than introducing a single serialization format, we enable end-users to output whatever format they want. If a particular user wants to serialize foreign keys using some exotic technique with local significance, they can subclass a base serializer make a simple modification rather than needing to duplicate an entire serialization backend. There are many existing tickets that are seeking to expand on the capabilities of the serialization framework; rather than implement a bunch of complex changes, I'd rather set up the framework that makes all those changes simple to implement, and more. Providing *a* CSV serializer may provide utility to *some* users. Providing a framework that allows for arbitrary serialization in *any* format, with *any* set of serialization conventions has the potential to be much more useful. Providing a base CSV serializer may be an important part of this change -- after all, CSV a bit of a pathologi
Re: Django on Google App Engine via SQL (not nonrel)
On Tue, Oct 26, 2010 at 7:23 PM, Alex Gaynor wrote: > It depends what you mean by "MySQL" compatible. If by that you mean > that it's importable as mysqldb and implements the exact API it should > work out of the box, more or less. However, if by that you mean it > implements PEP-249 you really need to ship a database backend for > Django (you probably want to do this anyway, I'll explain). Since > this is SQL backend this isn't quiet so much work. Database backends > basically consist of 2 things: a compiler, which is the core of the > SQL generation, and "the rest of it" which is a series of flags and > methods which make very small scale decisions about what features are > available and how certain constructs are translated into SQL. Also important is a creation module which knows how to map Django model field types to whatever the appropriate column types are in the data store. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: CSV serializer?
For what it's worth, here are some of the decisions that I made in the serializer I linked to above. - m2m values are serialized as comma separated values surrounded by brackets, like Python lists: "[1, 2, 3]" - The Python contstants True, False, and None are serialized as the strings "True", "False", and "None" respectively - The strings "True", "False", and "None" are serialized as the strings "'True'", "'False'", and "'None'" respectively - Multiple models can be serialized into a single stream, with header lines for each - The first line of a CSV stream must be a header line - The first two column headers are always 'pk' and 'model'. These are followed by the model's field names Based on Russell's enumeration of the various issues above, I can see how this approach is far from ideal. It makes a lot of assumptions that preclude it from being a general soultion. But it suits my needs and passes all the Django regression tests. :) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django on Google App Engine via SQL (not nonrel)
On Tue, Oct 26, 2010 at 9:31 PM, James Bennett wrote: > On Tue, Oct 26, 2010 at 7:23 PM, Alex Gaynor wrote: >> It depends what you mean by "MySQL" compatible. If by that you mean >> that it's importable as mysqldb and implements the exact API it should >> work out of the box, more or less. However, if by that you mean it >> implements PEP-249 you really need to ship a database backend for >> Django (you probably want to do this anyway, I'll explain). Since >> this is SQL backend this isn't quiet so much work. Database backends >> basically consist of 2 things: a compiler, which is the core of the >> SQL generation, and "the rest of it" which is a series of flags and >> methods which make very small scale decisions about what features are >> available and how certain constructs are translated into SQL. > > Also important is a creation module which knows how to map Django > model field types to whatever the appropriate column types are in the > data store. > > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > What James says is completely correct, this is another element of "how close to MySQL is it", for example all of the creation module may be a no-op if it retains the BigTable semantic of arbitrary key-value storage, or it may be exactly the same as the existing MySQL one, or somewhere in between. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
great!!
nice to see the Django guys involved, and should absolutely be google's #1 priority for app engine... however, we should be able to access the native datastore entities (if datastore is the base architecture for rel abstractions) for our own performance tuning purposes. and congrats to you Wesely on joining the Big G (just noticed it). Great to see python's heavyweights involved in this -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: It is real to add ticket #8054 to 1.3 milestone?
Hi Alex, Patch is looking good, except few small things. Wiki docs are also very good, but they are quite incomplete. Replied to the ticket. On Tue, Oct 26, 2010 at 11:23 PM, Alex Kamedov wrote: > Can anybody rewiew the patch? > > On Wed, Oct 13, 2010 at 6:35 PM, Alex Kamedov wrote: >> >> Hi All, >> I uploaded patch with tests and little improvements >> >> http://code.djangoproject.com/attachment/ticket/8054/8054-list-column.5.diff >> I think it ready for review. >> I really sorry, but I couldn't write good documentation because English >> isn't my own language. The maximum of my possibility in writing docs is >> here http://code.djangoproject.com/wiki/ListColumns For more examples see >> folder admin_listcolumn in regression tests provided by last my patch. >> Cheers, >> Alex Kamedov >> On Wed, Oct 13, 2010 at 2:12 AM, Gabriel Hurley wrote: >>> >>> Hi alekam, >>> >>> This is certainly the kind of ticket that we want to deal with in 1.3 >>> since it's been around so long and deferred a couple times. Starting >>> the discussion here is definitely the right way to make it happen. >>> >>> That said, at the very least it needs a thorough code review, a full >>> set of tests, and good documentation before it can be included. >>> >>> I'm not personally sold on the way the functionality is implemented, >>> but I'd have to think on what would be preferable. I'm sure others >>> will have stronger opinions on it one way or the other. >>> >>> All the best, >>> >>> - Gabriel >>> >>> On Oct 12, 9:47 am, alekam wrote: >>> > Hi All, >>> > >>> > I found very useful ticket #8054. This ticket has accepted status and >>> > assigned to brosher about 2 years. The problem describes on ticket >>> > detail page and in the >>> > wikihttp://code.djangoproject.com/wiki/ListColumns >>> > The ticket has patch witch passes all existing regression tests and I >>> > plan to write unit tests for it. >>> > It is real to add ticket #8054 to 1.3 milestone? >>> > >>> > Cheers, >>> > >>> > Alex Kamedov >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Django developers" group. >>> To post to this group, send email to django-develop...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> django-developers+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/django-developers?hl=en. >>> >> > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
prepopulated_fields javascript error since r14123
Has anyone else found that using prepopulated_fields in admin.ModelAdmin since r14123 produces a javascript error: "d.join is not a function"? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
