Admin interface not preventing simultaneous editing of the same record
After being unable to get any advice or further information via google, #django or the users' mailing list, I opened http://code.djangoproject.com/ticket/11652 regarding the admin interface not preventing simultaneous editing of the same record (or at least not providing that as an option). I guess this is not a typical usage scenario, but for my use case I would like to implement it if at all possible. My first thought was to try grab a JSON representation of the original record in an override of ModelAdmin.change_view; I thought I might be able to save this via extra_context and somehow get it back when change_view is called the second time for the HTTP POST of the modified record. I was hoping to then compare that saved JSON representation of the original record with the JSON representation of the record as it exists in the database on that POST call; if they differed then someone must have changed the record in the meantime and so I could generate an error message. I realized if I added an AutoField data to the record and saved that instead, then that would be a lot cheaper to save and compare, but I still don't know how to save that information. Is there a way to save information in the session and get it back on subsequent calls? Using an AutoField date it would probably be sufficient to just know when the original GET of the record happened for the user to start changing it. Is there a way to find that out? If anyone has any pointers or advice I'd be most grateful. Cheers, Dave --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Admin interface not preventing simultaneous editing of the same record
On Aug 11, 10:29 pm, Russell Keith-Magee wrote: > There are any number of ways to solve this problem by adding a field > to the model (autofield with an 'edit number', timestamp tracking last > edit time etc). However, these aren't really candidates for a general > solution. It didn't occur to me before, but would the History mechanism be any use here? It must already be tracking edits. > A few random thoughts: Thanks very much for those. I am digesting them now :-) I like the idea of doing this at the form level rather than adding anything to the model. > If this is a problem that interests you, then I encourage you to dig > around. Developing the code to implement this fix will certainly give > you a very good grounding in the internals of Django's form > infrastructure. If you can find a clean way to implement this > functionality, then we are certainly interested in integrating this > into the Django core. It definitely does, and if I can find a way to do it that would be useful to others that would be wonderful. I'm extremely impressed with Django in my limited-to-this-point use of it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Admin interface not preventing simultaneous editing of the same record
On Aug 12, 12:06 am, Russell Keith-Magee wrote: > Another cause for hesitation is that it would be an admin-specific > solution to the problem. A generic solution that would work for all > ModelForms would be nice if it is possible. Agreed. I shall look at that first since it's more generally useful. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Admin interface not preventing simultaneous editing of the same record
On Aug 12, 12:20 am, Alex Gaynor wrote: > Personally I think including > a JSON dump of the model with the page is the easiest solution, but I > could be convinced otherwise. I have made a little bit of progress: I already had a subclass of forms.ModelForm. I added a form field, overrode overrode __init__ to set the field's initial value to the json repr of the instance, and overrode clean() to do the comparison: http://pastebin.com/f3b2c03cb Problems: 1. The hidden field with the url-encoded json shows up on the webpage, which is good, but I get the colon between my empty string label and the hidden field, so it looks a bit odd. 2. I'm explicitly setting my hidden form field's "initial" attribute which must be wrong - it seems like I'm breaking encapsulation anyway. 3. The biggie: I haven't figured out how to grab the JSON back from the POST data, as I'm not clear where to do that - overriding the view somehow? So as it stands my changes are useless, since separate instances of my form are instantiated on the GET and the POST, and hence my comparison never fails - the JSON for my hidden field for the form instance created for the POST generates the JSON from the at-time- of-POST instance of the model, instead of grabbing the previously- generated JSON it from the hidden field in the POST data. Does it seem like I'm on the right track? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Admin interface not preventing simultaneous editing of the same record
On Aug 12, 12:20 am, Alex Gaynor wrote: > Personally I think including > a JSON dump of the model with the page is the easiest solution, but I > could be convinced otherwise. I have something that works now: http://pastebin.com/f1bd4c7a3 There's a big comment in the clean() method that explains it but it's basically looking at the value and initial-value of the hidden form field that has the JSON representation of the model in it. I based the extraction of the two values from the field on BaseForm's _get_changed_data() method. I'm sure I'm doing several of the operations in a less than ideal fashion, but it's working. I also need to figure out how to stop it from showing the label on the form the user actually sees - it's a blank label followed by a colon followed by a hidden field so all you see is this odd colon sitting there. --~--~-~--~~~---~--~~ 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: Decision required: PostgreSQL minimum versions
I think Redhat added a postgresql-server84 package in RHEL5.5 but that's in addition to regular postgresql-server (8.1) package, not instead of it. Postgres 8.1 is the standard version on RHEL5.x. Since RHEL6 is based on Fedora12, I believe it will use Postgres 8.4. On Jun 10, 8:23 am, Adam Nelson wrote: > I agree with Simon, Jerome et al. > > Django 1.3 should feel free to go to 8.3 as a minimum Postgres if > there are db backend changes that could take advantage of those > versions' capabilities. > > Ubuntu Hardy (the previous LTS) uses Postgres 8.3 and RHEL 5.5 uses > 8.4. > > It really seems to me that the Django project allows for underlying > databases to simply be too old. Django 1.2 will be supported until > Django 1.4 is out, so people have the option to continue using 1.2 for > a very long time if their organization has an exceedingly long upgrade > cycle internally. In my mind, people in such organizations aren't > installing Django updates until a year after the release anyway. > > With that knowledge, I would personally support Django 1.3 having > minimums of Postgres 8.3 and MySQL 5.0 (again, if there is actual code > written to take advantage of those versions, not just for the hell of > it). > > -Adam > > Postgres Feature Matrix:http://www.postgresql.org/about/featurematrix > > MySQL 5.0.51a on Ubuntu > Hardy:http://packages.ubuntu.com/hardy/mysql-server-5.0 > > PostgresSQL 8.3.11 on Ubuntu Hardy:http://packages.ubuntu.com/hardy/postgresql -- 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: request.is_ajax() and hidden iframe kludge => request.is_framejax()?
> This input field is easily fakeable. An attacker can't fake your > browsers XHR requests, which makes request.is_ajax somewhat secure and > trustable. I don't see how your solution could achieve that. is_ajax() simply checks an HTTP header. It is easily set by an attacker. On Jul 16, 2:30 pm, Florian Apolloner wrote: > Hi, > > On Jul 16, 7:25 pm, David De La Harpe Golden > > wrote: > > People doing ajax have probably hit the "XMLHttpRequest doesn't do file > > uploads (at least not non-browser-specifically), use a hidden iframe > > kludge or flash" issue. Anyway, maybe that will change one day > > It's already changing, modern browsers can do what you want (google > for html5 file uploads). I don't see any reason to support something > like you suggest; we should support standards and not workarounds > (just my opinion). Imo the best way currently is to use the new apis > and fallback to flash or whatever if needed (I actually guess flash is > the best fallback here). > > > The hidden-iframe requests will AFAIK show up with request.is_ajax() == > > False to django. So a "done thing" (I think) to distinguish between the > > non-ajax and hidden-iframe requests seems to be to just have an extra > > field to act as a pseudo-header, i.e. > > > > > This input field is easily fakeable. An attacker can't fake your > browsers XHR requests, which makes request.is_ajax somewhat secure and > trustable. I don't see how your solution could achieve that. > > > or "?X-Requested-With=ScriptedIFrame" > > Same as above. > > > It might nonetheless be nice for django to have some support for > > checking for some particular pseudo-header. > > -1, mostly due to the fact that it's something most people won't need > and you can easily inject that info using a middleware yourself. Hence > I am for solution A. > > Cheers, > Florian -- 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 Security
> > The suggestion that documentation of this issue be improved in the > docs is certainly a good idea -- even a special section on "stuff you > should know about security", with references to projects like OWASP > would be a worthwhile addition. > +1 on this. Would be great to see more documentation detailing && promoting best practices. Love regards etc David Miller 07854 880 883 www.deadpansincerity.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.
Logging all/slow queries
I think it would be useful to be able to log all queries and/or some "slow" subset of queries in production (DEBUG=False). I understand clearly the reasoning why queries are currently only logged in debug mode, but not all problems crop up in debug mode. This does duplicate some functionality of RDBMSs but aggregating queries across multiple databases is really convenient rather than having to go to each database's logs. More concrete proposal: - logging queries is disabled by default in production - add an option to log all queries (CursorTimingWrapper?) - add an option to log "slow" queries with a warning - neither of these will populate BaseDatabaseWrapper.queries -- 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: 1.2 Proposal: django debug toolbar in contrib
I think it's mostly only my fork (and it's forks) that vary much from trunk. I never got around to changing the framework to come in line with the master branch I think because it didn't support everything that was needed. Not sure if it does now however. On Aug 12, 4:00 pm, Rob Hudson wrote: > I'm not sure if this is the place but here are some other issues or > questions I have if this were to happen... > > * The jQuery question is a big one. I've taken strides to make the > debug toolbar interoperate with other popular JS frameworks (mootools > and prototype, namely). But if jQuery were decided against, would it > make sense to re-use some of the Javascript libraries that Django has > developed for its admin? Would it use the same admin media handler > trick? > > * Which set of plugins are included, and of those that have settings, > what are their defaults. Some defaults currently optimize to general > case and provide more debugging information, but on larger sites > performance may suffer severely. It may make sense to take a > philosophy of best default performance with opt-in added debugging. > > * Should there be a place for plugins (panels) that don't make the > cut? Panels consist of some Python and some HTML, so it's not a > single file. They *could* be changed to work similar to form.widgets > with a render method and HTML backed in... but I'm not a huge fan of > that. But it would make it a bit easier for posting on a site like > Django Snippets. > > * Should the UI match that of the Django admin (overall theme, colors, > etc)? > > * If the debug toolbar is incorporated, should we consider different > integration options? e.g. Currently the debug toolbar injects URLs > into the project in a rather ugly way -- could this be done better if > it were part of Django? > > Thanks, > Rob --~--~-~--~~~---~--~~ 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: 1.2 Proposal: django debug toolbar in contrib
Oh, and thats most likely my branch you're referring to Martin. I implemented a lot of the panels, and went so far as adding crazy monkey patching in some of them to catch some information I wanted. http://github.com/dcramer/django-debug-toolbar/tree/master On Aug 11, 11:38 am, Martin Maney wrote: > On Tue, Aug 11, 2009 at 09:50:35AM -0500, Alex Gaynor wrote: > > Right now django-debug-toolbar has a pretty stable panel interface and > > I actually can't recall it changing since release. A possibly more > > interesting issue is that some of the debug information it get's is > > somewhat of a hack, that is template data is gotten from monkey > > patching Template.render, the SQL data is also a monkeypatch. > > Caching stats were another area where monkeypatching seemed to be the > only alternative to an altered usage in one's source code. Back when I > spent some time using and extending parts of ddt the situation was as > described here: > > http://wiki.github.com/mmaney/django-debug-toolbar/cache-panel-workar... > > That predates the discussion I had with Rob Hudson about another fellow's > branch (can't recall whose offhand) which used a monkeypatch to add the > necessary intercept to the cache object. At one point I had hoped to > bend Jacob's ear at PyCon about this, but I got to be too busy with > other work and, in fact, never had time to drop in. Plus I had read > about how everyone was focusing on getting 1.1 out Real Soon Now and > figured it wasn't the best time for it. Months passed... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: JS library in admin and tools
On Tue, Aug 18, 2009 at 1:35 PM, Yuri Baburov wrote: > > In example, I want some django 3rd-party or contrib package with > autocomplete fields, ajax validation, ajax form sending and inline > property editing. > I want to be able to integrate it into admin interface and overall > interface in painless and fast way. > > What do you suggest me to do? > How do you see further django-and-js-related infrastructure in future? What a 3rd-party chooses to use to accomplish functionality is up to them. jQuery, plus most other libraries, have the ability to operate in a mode that doesn't cause conflicts with other libraries. As long as the 3rd-party Django app properly uses those features of the JS lib, this isn't an issue. That way, you can you whatever 3rd party app you want, and not have to worry about what javascript framework they may or may not have used. Integration to the admin can be normal via the normal avenues of admin customization -- namely, adding in your own forms, templates, and views. I'm not sure I see how what JS library is used to do things like AJAX is related. -- dz --~--~-~--~~~---~--~~ 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: About multilingual models
Hi Marc, hi list, First to get my email into context, I wrote a similar email some time ago, which does list some more options on how to do model translations and offers some kind of hybrid data model as a solution: http://groups.google.com/group/django-developers/browse_thread/thread/ca5987ea80120c63/cfffc43b9ec29738?#cfffc43b9ec29738 > Basically, I arrived to the conclusion that there are two different > approaches, both valid, and everyone more suitable depending on the > website. Let me name these methods "model based" and "gettext like". I like to dismiss the gettext-like approach, as it causes to much trouble. Starting with not being usable inside QuerySet's it may not give django users what they need and want when talking about model translations. A big problem I currently see is that changes to the original text may result in a lost translation as long as you only save the msgid<->msgstr-relation inside the database (as the msgid "changes"). So you would need to include hints like the model, it's pk and fieldname (as you suggest, too), but this makes the approach kind of hacky. What I think makes using a gettext like approach impossible is the need to translate fields you use to _find_ a row in the database. A slug might be needed to be translated for example. So you should be able to query by a slug, depending on your current language setting. A gettext like approach will probably definitely fail here. > model based method > - > > This method is specially interesting in websites where all translations > are provided at the same time. [...] > In this case the admin should allow filling all translations at the same > time, and if a field is required, it should be required for all languages. I don't think this is what makes a model based approach interesting. It's the "searchability". How you present your underlying data structure (database or gettext) to the user/admin should not be coupled to the data structure. You could make translations optional in both cases, with the limitation to force the user/admin to create at least one translation when using a model based approach (even this might not be needed for data-driven models). > In this case I would specify this syntax to let Django know that we want > this field translated: > class MyModel(models.Model): > my_i18n_field = models.CharField(max_length=32, translate=True) > Main advantage of this method is that we have the translate property > together with the field definition. This makes easy to know if a field > will be translated or not after coding the models. I still don't like putting the info about the translated fields inside the model. Why not use the registry based approach you used for your gettext like idea? As you can create dynamic models in django and by this can create the additional table. django-pluggable-model-i18n uses this, it seems to work. > From the database point of view I would create an extra table for every > model, with next structure: > * id > * main_table_id > * language_code > * field1 > * field2 > * ... > So, to get data would be necessary to join both tables filtering by > current language code. That would make easy to filter, sort or search by > any of the translated fields. Whats the big problem here, from a usability perspective, is the way you need to search the translated fields. Thinking about where the field is saved (model or translation), needing to join by yourself and still don't be able to fetch the translation itself with the model doesn't seem to be a real solution. Example: Book.objects.get(translation__language='en', translation__field='...') -> just fetches the book, without the translation (fetching the book will cause an additional query, for every book) -> needing to decide where your field lives may cause errors (and will make adding translated field more complex) -> you will always need to specify the language, this may cause errors, too Thats why I suggested a more easy usage in my original email: Book.objects.get(field='...') -> should know that "field" is translated and use the translation table -> should join the translation and select the translated fields (see original email about how this join needs to be done) -> should use the language of the request or some other default language without the need to tell it so (sites usually only display one translation at a time, of course there needs so exist some way to get all translations) Greetings, David Danier --~--~-~--~~~---~--~~ 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: I need a pony: Model translations (aka "my proposal")
Hi Veena,
first sorry for my late answer, I missed your email somehow.
The SomeObjTranslation-model is what should be dynamically created by
some registry. This registry is a little more difficult than your
suggestion, but should keep things simple enough:
-
class SomeObjTranslation(translation.ModelTranslation):
class Meta:
fields = ('some_field',)
translation.register(SomeObj, SomeObjTranslation)
-
Putting this into it's own class makes adding new attributes more easy.
Using the Meta-subclass allows future ModelTranslation's to add/override
fields to/of the original model and keeps this in sync with normal
models (ModelTranslation could be a subclass of models.Model, using its
own metaclass).
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Django Sites framework
Have you checked your INSTALLED_APPS for the sites app as well?
On Aug 20, 10:59 am, Vladimir Prudnikov wrote:
> I'm *not* using Sites framework ('django.contrib.admin' is not
> included in INSTALLED_APPS and SITE_ID is not defined), but there is
> an exception when I click on "View on website" link on the edit model
> page in admin interface.
>
> Exception Value: You're using the Django "sites framework" without
> having set the SITE_ID setting. Create a site in your database and set
> the SITE_ID setting to fix this error.
>
> There is no check that Sites framework is really used.
--~--~-~--~~~---~--~~
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: I need a pony: Model translations (aka "my proposal")
st translation as "is_base=True".
Anyway I'm not sure if this deserves to much attention. When writing my
proposal the idea was to implement translation.ModelTranslation (see
idea.txt) as a derivate of models.Model (This is one of the reason I
used a Meta subclass). When doing so the translation could itself add
fields that are not included in the original model (or perhaps even
overwrite some attributes in the original model?):
>>> class SomeObj(models.Model):
>>> foo = models.CharField(...)
>>> bar = models.CharField(...)
>>>
>>> class SomeObjTranslation(translation.ModelTranslation):
>>> is_base = models.BooleanField(default=False)
>>> class Meta:
>>> fields = ('foo',)
This way the translation system stays very extendable and may be used
for some version-tracking-scenario while not supporting this itself.
btw.: This is another reason why I want to always use a JOIN.
Greetings, David Danier
--~--~-~--~~~---~--~~
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: Replacing get_absolute_url, I am against it
Le 12 sept. 2009 à 15:20, Jacob Kaplan-Moss a écrit : > > On Sat, Sep 12, 2009 at 8:42 AM, Thomas K. Adamcik > wrote: >> In essence we could add only one new method to the API that returns a >> URL-object that provides access to the data: > > I like this idea a lot. It solves most of the problems I have with > get_absolute_url: > > * I dislike the name -- far too verbose. Why not just `obj.url()`? Note this option will break a lot of models with an existing url field (that's just a warning, as a devil's advocate, I'm not fond of the current name too...). Regards, David --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Let's Talk About ``to_field``
I haven't brought this up for quite a while, but ``to_field`` still does not function properly (at least as of 1.1, I haven't noticed any changes addressing it though). The issue is that anywhere you do a GET lookup, it doesn't process the to_field properly:: # TODO: waiting on to_field fix try: opt = cls.objects.get(business=business.business_id, key=key) except cls.DoesNotExist: opt = cls.objects.create(business=business, key=key, value=value) This seems to have been solved in the admin branch when newforms-admin landed, but seems mostly ignored in the core field's. This issue has also existed as far as I can remember, which is quite some time :) So, what do we need to get the ball rolling on this. I don't have much time myself to commit, but if it's minor things such as writing some tests that easily reproduce all errors we've found. We'll glady commit those. Other than though my day is just filled, but I'd love to see this get fixed. It's something that's advertised as a core feature, has been for 3+years, and simply doesn't work. On a side note, something that I also believe is a bug, is that ManyToManyRel.get_related_field() returns the primary key field no matter what. I'm not sure if thats the intended functionality of that or not, but to me it sounds like this should refer to the field in the through model (even if that model is virtual) that it's pointing to. --~--~-~--~~~---~--~~ 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: Session/cookie based messages (#4604)
I'm a bit late in here, and it seems we reinvented a wheel as well (even tho we did this about a year ago), but recently just OS'd our simply notices system [1]. I'm also +1 for including something like this in trunk rather than using the current user messages. I had a brief look at django_notify and its a similar approach, but it seems much more configurable than what we wrote. [1] http://github.com/dcramer/django-notices On Sep 22, 9:49 pm, Tobias McNulty wrote: > On Tue, Sep 22, 2009 at 9:51 PM, Russell Keith-Magee > > wrote: > > In reality, I get a ping time closer to 300 ms. And that's to a > > high-end data center under ideal conditions - it can be much larger if > > I'm dealing with low end providers. > > What?? 200 ms is the average quoted by Mr. Sproutcore himself! > > No, in all seriousness, my apologies for making such a broad generalization > about packet latency. I could/should have said 500 ms or even a second; the > argument and corresponding solution, if needed, remain the same. > > Anyways..we digress. I am marking this a non-issue in my own head - please > pipe up if there's a case to be made. > > Tobias --~--~-~--~~~---~--~~ 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: Let's Talk About ``to_field``
As usual, my apologies for lacking context :) The problem happens when you try to query with a model containing a foreign key that references a to_field. It fails to pass the proper attribute. # Exampe 1, a simple get lookup class ExampleBrokenModel(models.Model): user = models.ForeignKey(User, to_field="username") user = User.objects.get(username="a_username") # The following will fail due to the fact it's going to try to do user_id= user.pk, rather # than user_id=user.username ExampleBrokenModel.objects.get(user=user) I will attach additional tests to a ticket, see also [1] I'm not aware of this ever working properly, but I'm not going to dig up tickets. You can take my word for it as we've been dealing with it at this project for a year, and had been working with Django almost 2 years before that. Either way, it's not a big deal, the fact is it doesn't work as advertised, and it is advertised. You would have to talk to the author of newforms-admin, which I believe was Brian Rosner. There is some special code for handling to_field lookups in the admin. [1] http://www.pastethat.com/LUYWh David Cramer On Wed, Sep 23, 2009 at 6:27 PM, Karen Tracey wrote: > On Wed, Sep 23, 2009 at 4:59 PM, David Cramer wrote: > >> >> I haven't brought this up for quite a while, but ``to_field`` still >> does not function properly (at least as of 1.1, I haven't noticed any >> changes addressing it though). The issue is that anywhere you do a GET >> lookup, it doesn't process the to_field properly:: >> >># TODO: waiting on to_field fix >>try: >>opt = cls.objects.get(business=business.business_id, >> key=key) >>except cls.DoesNotExist: >>opt = cls.objects.create(business=business, key=key, >> value=value) >> >> > That's supposed to illustrate the problem with to_field? It's a snippet of > code lacking any context with a cryptic TODO comment. What is the model > definition here (which would at least give a clue where to_field applies)? > How would this code be different if this "to_field fix" were applied? > > This query: > > > http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&summary=~to_field&order=priority<http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&summary=%7Eto_field&order=priority> > > shows 4 open tickets with the "to_field" in their summary. Is the problem > you are referring to one of these? > > >> This seems to have been solved in the admin branch when newforms-admin >> landed, but seems mostly ignored in the core field's. This issue has >> also existed as far as I can remember, which is quite some time :) >> >> > I've not been around as long as you so without reference to a ticket or > something unfortunately I have no idea what problem you are talking about. > I also don't know what you mean by it being fixed in admin but not in "core > fields". Admin doesn't define fields, so huh? I can't really parse what > you are trying to say here. > > > >> So, what do we need to get the ball rolling on this. I don't have much >> time myself to commit, but if it's minor things such as writing some >> tests that easily reproduce all errors we've found. We'll glady commit >> those. Other than though my day is just filled, but I'd love to see >> this get fixed. It's something that's advertised as a core feature, >> has been for 3+years, and simply doesn't work. >> >> > The tests you mention filed in a ticket, or attached to one of those > tickets from above if indeed one of those is reporting the problem you are > talking about, would be helpful. If none of those tickets reflect the > problem you are talking about, then a complete description of the problem > would be helpful; as it is I have no idea what problem you are referring > to. > > >> > > On a side note, something that I also believe is a bug, is that >> ManyToManyRel.get_related_field() returns the primary key field no >> matter what. I'm not sure if thats the intended functionality of that >> or not, but to me it sounds like this should refer to the field in the >> through model (even if that model is virtual) that it's pointing to. >> > > A filed ticket describing the problem and how to recreate it would have a > better chance of getting remembered and fixed than a side note in an email. > > Karen > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Let's Talk About ``to_field``
I believe someone had linked a ticket before, but I was unable to find one, so I went ahead and submitted it here: http://code.djangoproject.com/ticket/11938 David Cramer On Wed, Sep 23, 2009 at 6:41 PM, David Cramer wrote: > As usual, my apologies for lacking context :) > > The problem happens when you try to query with a model containing a foreign > key that references a to_field. It fails to pass the proper attribute. > > # Exampe 1, a simple get lookup > class ExampleBrokenModel(models.Model): > user = models.ForeignKey(User, to_field="username") > > user = User.objects.get(username="a_username") > > # The following will fail due to the fact it's going to try to do user_id= > user.pk, rather > # than user_id=user.username > ExampleBrokenModel.objects.get(user=user) > > I will attach additional tests to a ticket, see also [1] > > I'm not aware of this ever working properly, but I'm not going to dig up > tickets. You can take my word for it as we've been dealing with it at this > project for a year, and had been working with Django almost 2 years before > that. Either way, it's not a big deal, the fact is it doesn't work as > advertised, and it is advertised. > > You would have to talk to the author of newforms-admin, which I believe was > Brian Rosner. There is some special code for handling to_field lookups in > the admin. > > [1] http://www.pastethat.com/LUYWh > > > David Cramer > > > > > On Wed, Sep 23, 2009 at 6:27 PM, Karen Tracey wrote: > >> On Wed, Sep 23, 2009 at 4:59 PM, David Cramer wrote: >> >>> >>> I haven't brought this up for quite a while, but ``to_field`` still >>> does not function properly (at least as of 1.1, I haven't noticed any >>> changes addressing it though). The issue is that anywhere you do a GET >>> lookup, it doesn't process the to_field properly:: >>> >>># TODO: waiting on to_field fix >>>try: >>>opt = cls.objects.get(business=business.business_id, >>> key=key) >>>except cls.DoesNotExist: >>>opt = cls.objects.create(business=business, key=key, >>> value=value) >>> >>> >> That's supposed to illustrate the problem with to_field? It's a snippet >> of code lacking any context with a cryptic TODO comment. What is the model >> definition here (which would at least give a clue where to_field applies)? >> How would this code be different if this "to_field fix" were applied? >> >> This query: >> >> >> http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&summary=~to_field&order=priority<http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&summary=%7Eto_field&order=priority> >> >> shows 4 open tickets with the "to_field" in their summary. Is the problem >> you are referring to one of these? >> >> >>> This seems to have been solved in the admin branch when newforms-admin >>> landed, but seems mostly ignored in the core field's. This issue has >>> also existed as far as I can remember, which is quite some time :) >>> >>> >> I've not been around as long as you so without reference to a ticket or >> something unfortunately I have no idea what problem you are talking about. >> I also don't know what you mean by it being fixed in admin but not in "core >> fields". Admin doesn't define fields, so huh? I can't really parse what >> you are trying to say here. >> >> >> >>> So, what do we need to get the ball rolling on this. I don't have much >>> time myself to commit, but if it's minor things such as writing some >>> tests that easily reproduce all errors we've found. We'll glady commit >>> those. Other than though my day is just filled, but I'd love to see >>> this get fixed. It's something that's advertised as a core feature, >>> has been for 3+years, and simply doesn't work. >>> >>> >> The tests you mention filed in a ticket, or attached to one of those >> tickets from above if indeed one of those is reporting the problem you are >> talking about, would be helpful. If none of those tickets reflect the >> problem you are talking about, then a complete description of the problem >> would be helpful; as it is I have no idea what problem you are referring >> to. >> >> >>> >> >> On a side note, so
Re: Model.objects.raw() (#11863)
Russ, On 29 Sep 2009, at 03:25, Russell Keith-Magee wrote: > (1) know about the trick of instantiating an object with the > unrolled list version of a cursor, and Any chance you could expand upon this? -- David Reynolds da...@reynoldsfamily.org.uk --~--~-~--~~~---~--~~ 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: Session/cookie based messages (#4604)
The proposal per your email is more or less how django-notices works.
Sent from my iPhone
On Oct 10, 2009, at 12:53 PM, Tobias McNulty
wrote:
>
> On Sat, Oct 10, 2009 at 1:19 PM, Tobias McNulty > wrote:
>> Things that still need to be discussed/done:
>>
>> * Coming to consensus on what 3rd party app we actually choose to
>> extend/modify to fit into Django
>>
>> * What to do with the existing user message API (see
>> http://code.djangoproject.com/wiki/SessionMessages#IntegratingwiththeExistingAPI
>> )
>>
>> * Review/add to the TODO list on the wiki
>> (http://code.djangoproject.com/wiki/SessionMessages#TODOOnceaSolutionisChosen
>> )
>
> I should have also added:
>
> * Coming to consensus on a de facto standard API suitable for
> inclusion in Django
>
> I originally put it on the TODO list, but in retrospect the discussion
> needn't wait till we pick a solution.
>
> As a practical starting point, I copied the API for django-notify to
> the wiki page. I like the general form of that API, but I'd be
> slightly more happy with something like:
>
> from django.contrib import messages
>
> request.messages.add('message', messages.INFO)
> # or
> request.messages.add('message', classes=(messages.WARNING,))
> # or
> request.messages.error('message')
>
> A la python logging, I think endorsing a specific set of message
> classes or tags (but still allowing them to be extended) is A Good
> Thing because it helps reusable apps provide more customized feedback
> in a standard way.
>
> Tobias
> --
> Tobias McNulty
> Caktus Consulting Group, LLC
> P.O. Box 1454
> Carrboro, NC 27510
> (919) 951-0052
> http://www.caktusgroup.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-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: Session/cookie based messages (#4604)
I also don't think this problem is being addressed here. Yes you could pass messages to the context, but you would lose the ability to retrieve those variably. I believe storing it in the existing session is the best appoach for django's builtin support. Sent from my iPhone On Oct 10, 2009, at 8:00 PM, Tobias McNulty wrote: > > On Sat, Oct 10, 2009 at 7:03 PM, veena wrote: >> Today I was on very bad wifi connection. Constantly dropped. 20 >> seconds to load a page. >> I save in admin in two tabs and got a notice in one tab from the >> other >> tab. >> >> But I agree, I defer this "bug" for the first release od django >> messaging. I think django isn't now in right mood to add there some >> functionality like adding of query parameters to response object by >> some application. Maybe in future. > > AFAIK this will become a non-issue with the advent of HTML5, as each > window/tab will have its own session. > > Tobias > -- > Tobias McNulty > Caktus Consulting Group, LLC > P.O. Box 1454 > Carrboro, NC 27510 > (919) 951-0052 > http://www.caktusgroup.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-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: Session/cookie based messages (#4604)
I would definitely say it needs to be configurable then at the least. As using cookies to send messges is fine if you guarantee the entity is removed onthe next hit. Otherwise it becomes a performance issue storing them for longer periods of time. While I don't think that is common it should definitely be a factor in the decision. Sent from my iPhone On Oct 12, 2009, at 9:39 AM, Tobias McNulty wrote: > > On Mon, Oct 12, 2009 at 10:21 AM, David Cramer > wrote: >> I also don't think this problem is being addressed here. Yes you >> could >> pass messages to the context, but you would lose the ability to >> retrieve those variably. I believe storing it in the existing session >> is the best appoach for django's builtin support. > > I'm not exactly sure what problem you see as not being addressed, and > I don't think you were arguing against this, but it has been noted > elsewhere that it's more desirable to store the messages directly in a > cookie, if possible, to avoid the extra database or cache hit. > > It seems well worth it to me and there are solutions out there that > try to store the messages in a cookie and then fall back to the > session for longer (>4kb) messages. > > Tobias > -- > Tobias McNulty > Caktus Consulting Group, LLC > P.O. Box 1454 > Carrboro, NC 27510 > (919) 951-0052 > http://www.caktusgroup.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-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: Session/cookie based messages (#4604)
I'm -1 on adding .errors or whatever. The main reasoning being that "levels"
are simply numeric values (even though django-notices does provide default
labels for its built-ins). Regroup is very easy and I don't think this is
something that needs built-in, as there's no better way to optimize it than
regroup. However, with doing this it'd be very important that it doesn't
clear the messages unless you're pulling it out. django-notices handles this
by popping out elements in the iter (I believe), so that if you don't pop
the message out, it's still present.
David Cramer
On Mon, Oct 12, 2009 at 11:19 AM, Paul McLanahan wrote:
>
> On Mon, Oct 12, 2009 at 12:11 PM, Tobias McNulty
> wrote:
> > I have no particular issue with allowing messages to be iterated in
> > full and/or by type. We could also just sort the messages and let you
> > use {% regroup messages by tag %}, but I suppose you want the ability
> > to pull out a particular type of error and that could get tedious with
> > {% regroup %}.
>
> I think regroup would be fine. My thought was that with iteration by
> type you'd be able to easily highlight just one type if you so choose,
> and even have any of the types displayed in a completely different
> area of the markup if you needed. Having both abilities would be the
> best-of-all-possible-worlds in my opinion, but this is starting to
> smell like scope-creep. I'll just say that the backends and API are
> the most important things, and having individually iterable lists is
> just a "nice to have." I'd definitely be happy to help with the
> implementation though if the group thinks it a worthy feature.
>
> Paul
>
> >
>
--~--~-~--~~~---~--~~
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: Session/cookie based messages (#4604)
Sorry for the misunderstanding, I was talking specifically on retrieval of
messages. I definitely see no reason not to keep it in line with the logging
module in terms of errors/warnings/info messages. However, using things to
"retrieve all error messages" should be left up to the user. It's no quicker
doing it internally than it is using itertools.groupby or regroup in a
template.
David Cramer
On Mon, Oct 12, 2009 at 1:32 PM, Tobias McNulty wrote:
>
> On Mon, Oct 12, 2009 at 2:02 PM, David Cramer wrote:
> > I'm -1 on adding .errors or whatever. The main reasoning being that
> "levels"
> > are simply numeric values (even though django-notices does provide
> default
> > labels for its built-ins). Regroup is very easy and I don't think this is
> > something that needs built-in, as there's no better way to optimize it
> than
> > regroup. However, with doing this it'd be very important that it doesn't
> > clear the messages unless you're pulling it out. django-notices handles
> this
> > by popping out elements in the iter (I believe), so that if you don't pop
> > the message out, it's still present.
>
> In Python logging the levels are integers, but you still get
> convenience methods like logger.error('msg'), etc.
>
> I don't see why a similar method to filter the messages by type would
> be a bad thing.
>
> For the record I have no personal need for this feature (and hence
> strong feelings about it), but nor do I see why adding it would be a
> bad thing IF the need is actually there. Right now it sounds like
> regroup will work fine for its original proponent, so, in the interest
> of keeping things simple, let's assume it will not be included unless
> someone brings up a compelling case.
>
> Tobias
> --
> Tobias McNulty
> Caktus Consulting Group, LLC
> P.O. Box 1454
> Carrboro, NC 27510
> (919) 951-0052
> http://www.caktusgroup.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-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: Session/cookie based messages (#4604)
I don't agree with one calling doing logging and notices. There's really no reason to mix in logging with the notices framework as they serve completely different purposes. I believe Russel is just suggesting the APIs match so that there is no additional learning curve, which makes complete sense. David Cramer On Tue, Oct 13, 2009 at 2:53 AM, Hanne Moa wrote: > > On Tue, Oct 13, 2009 at 09:27, Russell Keith-Magee > wrote: > > I'm just > > noting that adding Django support for Python logging is also on the > > cards for v1.2, and it seems weird that we would introduce two APIs > > with similar external APIs, but not try to maintain parity. > > In fact, it would be very useful to both log and add a message at the > same time, iff there is an error. So that shouldn't deliberately be > made hard to do but maybe suitable for a lazy man's shortcut: one call > that does both. > > > HM > > > > --~--~-~--~~~---~--~~ 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: Session/cookie based messages (#4604)
I agree, this is 30 minutes of work to change the usage in Django, and it should be done with the inclusion of the messages patch. David Cramer On Fri, Oct 16, 2009 at 1:08 PM, Tobias McNulty wrote: > > On Fri, Oct 16, 2009 at 5:10 AM, Luke Plant wrote: > > I think this means that either the deprecation cycle would have to > > pushed back one (i.e. pending deprecation warning in 1.3, deprecation > > in 1.4, removed in 1.5), or core/contrib should be fixed by 1.2. I > > would strongly prefer the latter, and this would affect my vote: I > > don't want two messaging systems in Django, and if user messages are > > not deprecated, then we do have two systems. > > I agree that using deprecated code in the core is setting a bad > example. A quick review of the code shows 8 calls to > message_set.create: 3 in auth, 2 in admin, and 3 in the > create/update/delete family of generic views. This definitely sounds > to me like a manageable update for 1.2. > > Per feedback from Jacob, Chris, and Luke, I updated the notes on the > existing API, the transition plan, and the potential API on the wiki: > > http://code.djangoproject.com/wiki/SessionMessages > > Cheers, > Tobias > > > -- > Tobias McNulty > Caktus Consulting Group, LLC > P.O. Box 1454 > Carrboro, NC 27510 > (919) 951-0052 > http://www.caktusgroup.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-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: shortcut proposal
Le 16 oct. 2009 à 23:15, Sean Brant a écrit :
> Using a decorator allows you to do cool things like
>
> @provides_html('myapp/mypage.html')
> @provides_json(optional_serialize_callback_can_go_here)
> def my_view(request):
>return {'foo': 'bar')
>
> Then your provides_* could check the accept-header and know how to
> response. Html renders a template and json would serialize the dict.
It reminds me a proof of concept: http://code.welldev.org/djangorators
You can chain a lot of decorators but it will lead to hardly readable
code, mostly because the order matters.
Anyway, it's interesting to see that a lot of people are thinking
about the same approach...
David
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
#9200 - working to resolve any issues
I'm back at this one since it apparently is around +0 in the voting, though it still does not have a committer. I've updated the diff to work against trunk, and fixed some documentation errors. However, I'm not able to attach a file to the ticket. I receive this error: 403 Forbidden (TICKET_ADMIN privileges are required to perform this operation) In addition to that, I'd like to consider addressing the issue brought up by "anonymous": It fails with PicklingError if there are any formsets in the forms But I'm afraid I don't have much experience with formsets, and specifically don't have enough knowledge to modify one of my tests in order reproduce the issue. If someone has time, I'd very much appreciate it if they could look at my patch and indicate how could I modify the tests to cover formsets. Also, I still have Jacob's comment about extracting common functionality to a BaseWizard class in the back of my mind. I'd appreciate it if anyone has some direction on that. Thanks, Dave -- 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=.
Re: Session/cookie based messages (#4604)
I'm with Luke on this for the exact reasons he describes. Sent from my iPhone On Dec 5, 2009, at 7:24 PM, Russell Keith-Magee wrote: > On Sun, Dec 6, 2009 at 10:28 AM, Luke Plant > wrote: >> On Sunday 06 December 2009 00:56:56 Russell Keith-Magee wrote: >> Really? Files definitely seem to be more on the "storage" side of things: http://code.djangoproject.com/browser/django/trunk/django/core/fi les/storage.py >>> >>> The problem we have here is that we have all sorts of >>> inconsistencies introduced by history. Yes, files and templates >>> use function/class level specifiers, but db, session, cache, and >>> email all use module level specifiers. Module level specifiers >>> have the majority at this point, and personally, I prefer the >>> module approach - it shortens the user configuration strings, and >>> it enforces good usage of modules. >> >> I would have to question "enforcing good usage of modules"! It >> enforces a *single* way of using modules, that is, one class per >> module. > > The fact that it is one class per module is, IMHO, incidental. It's > one *concept* per module - one *backend* per module that I consider to > be a design pattern worth enforcing. > >> That is not necessarily 'good', it certainly isn't Pythonic >> in my experience, and it could well be bad. As such, it would be >> opinionated in a bad way - it forces other developers to have a >> proliferation of modules which might be very inconvenient. Why not >> just leave the decision in the hands of the people who are writing >> and >> organizing the code? We are all consenting adults here. > > The only time I can see this as inconvenient is if you want to put two > backends in the same module - to which I say you should have two > modules anyway. > > A part of my like for modules is the aesthetic of the end settings: > > BACKEND = 'path.to.module.backends.cookie.CookieBackend' > > vs > > BACKEND = 'path.to.module.backends.cookie' > > I vastly prefer the latter for the duplication it avoids. > >> In addition to the arguments in my other message, you also have the >> case where some third party writes a backend, and then realises they >> need another. So, they had: >> >> acme.messages.MessageStorage >> >> and just want to add >> >> acme.messages.SuperMessageStorage >> >> Instead, they are forced to move code around so each of these can >> live >> in its own module, or else have stub modules that serve no purpose >> except to appease the Django-gods. > > Again, I call this good code modularity. It may well be that the > second module requires nothing but an import and a configuration of > the first, but I would still argue that it would be good practice to > use two modules. > >> I agree that it would be good to be consistent if possible, but I >> would also like to see the better convention used, and the e-mail >> system could just as easily be changed as the messages system at this >> point, which would swing the majority the other way (it's actually >> currently "4-all" by my count, and that doesn't include the other >> configurable callables and classes, such as TEST_RUNNER, >> CSRF_FAILURE_VIEW, context processors, middlewares and view >> functions, >> which all use full paths). And #6262 could also go the other way too. > > I'm not sure I pay the comparison with middlewares, context processors > and the like. A middleware is, by definition, just a class. Off the > top of my head, I can't think of any examples where a middleware > module is split into submodules - most apps just define a middleware > module and put all relevant middlewares in that module. Hence, there > is no namespace duplication. > > On the other hand, backends are consistently broken into submodules, > because they're a lot more complex. The backend isn't defined by a > single class - conceptually, there's can be multiple classes, support > data structures, etc. The database backends are the best demonstration > of this, but IMHO the broader concept exisis and is worth preserving > in other backends. > > However, I'm also willing to admit that personal preference is a > factor here. We may just need to push this up for a BDFL judgement. I > would certainly prefer module level definitions, but at the end of the > day, I don't think I'd lose much sleep if the decision went the other > way. > > 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-develop...@googlegroups.com. To unsubscribe from this group, send
Re: Ticket #5025 - truncate filter, why hasn't it been accepted?
On Wed, Dec 30, 2009 at 1:37 PM, Ian Kelly wrote: > All of which could be handled just as well or better using CSS, unless > there's something I'm missing, which is the reason I asked. Using CSS to truncate email addresses defeats the purpose of truncating email addresses. Not exactly "better", is it? CSS is not a universal panacea. -- dz -- 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 #5025 - truncate filter, why hasn't it been accepted?
On Wed, Dec 30, 2009 at 3:29 PM, Alex Gaynor wrote: > The video I linked earlier had a critical point that I think a lot of > people are missing, adding a single filter may not add a lot to the > developer's burden directly but it impacts the perceptions (and > realities) of what kinds of things are reasonable for inclusion in > core. No one's ignoring that. But the truncate filter, specifically, isn't breaking new ground in terms of included filters. There's *already* a truncatewords filter. Adding this will not meaningfully impact the perceptions of core. -- dz -- 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: Model validation incompatibility with existing Django idioms
For us we definitely use this behavior, and I'm guessing this is about to bite us in the ass. I would think a simple fix would be to have a commit=False, and validate=True keyword arg. By default, validate is NoInput, but if commit is False it defaults to False. Wouldn't that be a simple enough backwards compatible workaround? On Jan 7, 10:40 am, Honza Král wrote: > Hi everybody, sorry for the late reply, was busy. > > Just to add few points that lead us to do it this way: > > ModelForm has a save() method that saves the model. It is reasonable > to assume that if the form is valid, the save() method call should > succeed, that's why the entire model is validated. > > We could create a PartialModelForm, that would have save() method only > when editing (and not adding) models and have other method (or > enforced commit=False) for retrieval of the partial model. This form > would only call validation on the modelfields that are part of the > form (not being excluded). This is the behavior I understand everybody > expects from ModelForm, so, for backwards compatibility, we could call > it just ModelForm. > > Also please mind that it could prove difficult to do half the > validation in one place and other fields elsewhere without a form. > Models, as opposed to forms, don't have a state in sense of > validated/raw and they don't track changes to their fields' data. > That's why validation is run every time and the results are not cached > on the instance. > > Few quick questions to get some ideas: > > 1) If editing a model (passed an instance parameter to __init__), even > with a partial form, do you expect model.full_validate being called? > > 2) Are you OK with ripping save(commit=False) functionality to some > other method? (current functionality can stay with a deprecation > warning for example) > > 3) Would you want errors raised in model validation after it being > created by a form (commit=False) to appear on the form? > > on subject of inlines: > 1) Is it acceptable to create a model and not it's inlines in the > admin if the modelform validates but the inlines don't? > > 2) How can we limit people's validation code to avoid validating FKs > in inlines since users can (and should) create their own validation > logic on Models? Especially when we try and treat admin as "just a > cool app" and not something people should really design for. > > 3) How would you feel on creating an option to enable behavior (1) ) > and document that models with side effects in their save and delete > should really go for that? > > 4) Making 3) the default and enable switching it off if people want > their admin page to save atomically. > > Please let me know what you think > > Thanks! > > Honza Král > E-Mail: honza.k...@gmail.com > Phone: +420 606 678585 -- 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: What The Enterprise wants from Django
The first three have been huges ones with us. We're just now running into the settings issue, but would love to see what people can come up with for solutions (we dont have a good one). Glad to see multi db is finally shipping, and excited to see what can be done for startup procs. On Jan 19, 3:26 pm, Jacob Kaplan-Moss wrote: > Hi folks -- > > I had a conversation this morning with one of my clients. In the > interests of being a good corporate citizen I'll refrain from > mentioning who other than (a) they're big (Fortune 1000), (b) you've > heard of them, and (c) they're using Django. > > Before our chat, they'd invited any engineers internally to bitch > about Django, and they shared some of the pain points they'd come > across. I took some notes; the really good news is that it's a short > list, and we already know about most of it. > > Before I share the list, I should mention that I'm not arguing we have > to immediately devote resources to these problems, nor even that we > have to solve them. I'm sharing this just as food for thought, and as > a perspective from a class of developers who mostly don't participate > in our process at all. > > So: > > The main issue they have is multiple database support. Music to my > ears (and especially Alex's :) since it looks like 1.2 will solve most > (all?) of their issues. My main takeaway from this point was that the > best way to please companies like this one will be to ship 1.2 on > time. Which will happen. So we rock. > > The next big one was the "startup signal" issue -- they've got lots of > code that needs to run at startup time, and there's no great mechanism > to do that currently. The core devs have talked about this one a *lot* > over the years, and it's obviously a hard one -- for one, there's no > clear definition of what "startup" means -- but a common theme seems > to be that bigger, more complex applications need some way to cleanly > run one-time, expensive startup tasks. > > Next, we discussed the difficulty of maintaining large installations > with multiple sites, a plethora of apps, and unspeakable possible > combinations thereof. Django's settings mechanism is simple and easy > to use, but once you have hundreds of sites it starts getting really > tricky to keep things in sync across hundreds of settings files. We > talked at some length about different possibilities for dynamic > settings infrastructure; this would especially come in handy for folks > wanting to build application servers/services like App Engine or the > nascent Toppcloud. > > If you've not yet checked out Toppcloud, do so now. I'll > wait. > > Finally, we ruminated over the difficulties in building rich internet > applications. Sure, writing HTML/CSS/JS/Python/SQL by hand works fine, > but we doesn't really have a good answer for the people who want > something IDE or GUI-ish. Meanwhile, Adobe and Microsoft are putting > all sorts of marketing dollars into Flex/Silverlight, and although > HTML5 can do some amazing things, the lack of tooling is a big danger. > (I've written at more length about this in the > past:http://jacobian.org/writing/snakes-on-the-web/#s-rich-web-applications). > > Of course, there may not be much us backend folks can do about this > problem -- I'm certainly not enough of a GUI application guy to be > able to even start to think about this problem -- but the lack of an > end-to-end solution will nonetheless put some off from writing web > applications with open source tools. > > So there we are. This is very much a brain dump, and I don't really > expect any concrete action to result from it. However, I found some > really interesting stuff there, and I thought I'd share. > > Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: QuerySet.exists() - Possible bug?
MySQL, in this situation, would have to actually select a row to
return a result, so it's slower. If it was just select 1 as a from
table where indexed_value = N, it doesn't even hit the tables, just
the indexes.
It's definitely not more efficient, and probably just an oversight
somewhere.
On Feb 10, 7:35 am, Jeremy Dunck wrote:
> On Wed, Feb 10, 2010 at 2:05 AM, Karen Tracey wrote:
>
> ...
>
> >> * What version of Django (including SVN revision, if appropriate) are
> >> you using?
>
> > I tried current trunk and backed off to the changeset where the function was
> > added -- query was the same. Looking at the idiom it replaced, the extra
> > select of the constant 1 value as 'a' was followed by a values('a') that
> > turned the result into a ValuesQuerySet. I don't see where this is being
> > done with the exists() implementation. As a result it seems to be a regular
> > QuerySet with a query with default_cols=True, resulting in all the default
> > columns getting pulled into the query.
>
> It seems odd to me that adding columns to the result of a returned row
> would be significantly slower than the PK. It also seems to me that
> using the default ordering might be unnecessary overhead, too.
>
> But I wonder if different DBs return different things based on the
> columns in the select clause? Perhaps Malcolm had a reason for making
> the change. :-/
--
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: examples directory
It's already been done orokusaki. The examples were (humbly) horrible as well. No template usage, just generic HttpResponse. That's basic Python, and docs > examples (in code). On Feb 15, 11:52 pm, orokusaki wrote: > -1 I think examples, broken or working, are very helpful for absolute > beginners. Maybe there should be strict warnings about the quality of > the code (in a similar fashion to the ones that warn you when you view > old docs). -- 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: admin javacripts
>
>
> var $jQD = jQuery.noConflict();
>
>
> And somebody else includes this:
>
>
>
> Then Django's version of jQuery would be available to all widgets as
> $jQD and the other jQuery version would still be available as $ or
> jQuery.
This kind of sounds nice, but perhaps some sort of django namespace
could be introduced. Meaning $jQD -> dj.$:
var dj = {};
dj.$ = dj.jQuery = jQuery.noConflict(true);
Greetings, David Danier
--
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: EmailBackends
On 22 Feb 2010, at 17:48, Mat Clayton wrote: > We run our own custom EmailBackend, and for the most part the new Email > Backend system has been fantastic, however recently I just found a > limitation, which I'd like to raise briefly to see if anyone else has it, or > can suggest an obvious solution Ive missed. > > We currently have a queued email backend which communicates with external > services to send email on our behalf. When our main newsletters go out, this > causes a huge spike in the system and queues pile up. This is fine except > that we want some email to now bypass the queue, for example registration > emails. This is because the queues often take 3-4 hours to process and this > is an unacceptable delay for signup emails. So essentially we would like to > be able to use a different backend for different circumstances, or be able to > pass args/kwargs into the backend from the send() to allow the EmailBackend > to make the appropriate routing changes. > I guess you need to somehow give your emails a priority, so that you can prioritise your signup emails over the newsletters. You might want to look at how django-mailer [0] does it. 0 - http://github.com/jtauber/django-mailer -- David Reynolds da...@reynoldsfamily.org.uk -- 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: proposal: ask a queryset to not raise exceptions
I definitely would like to see this handled in Django, but not in the
way mentioned. I personally think there does not need to be an option
for what it raises. I think of this in the situations where find
methods return either a -1, or an Exception, based on which method you
call.
Now I can't come up w/ any reasonable alternatives, and a param
to .get() is bad simply due to the fact that i'd reserve a column
name, but something like
Model.objects.get() -- raises DoesNotExist
Model.objects.get_when() -- returns None
On Mar 7, 4:14 pm, Vitaliy Kulchevych wrote:
> http://code.djangoproject.com/ticket/5741
>
>
>
>
>
> On Sun, Mar 7, 2010 at 11:48 PM, Chris wrote:
> > In my projects, I use this pattern a lot:
>
> > try:
> > obj = SomeModel.objects.filter(**crazy_filters_here).latest()
> > except SomeModel.DoesNotExist:
> > obj = None
>
> > Basically, I throw a filter at a queryset and if some value comes out,
> > I use it, If the filter happens to filter out all rows, I want the
> > queryset to return None. The way it works now is kind of tedious. I
> > can understand in some instances a DoesNotExist exception is whats
> > best, but other times, it would be best to just return None.
>
> > This I think would be better:
>
> > obj =
> > SomeModel.objects.filter(**crazy_filters_here).empty(raise=None).latest()
>
> > if you want the old behavior:
>
> > obj =
> > SomeModel.objects.filter(**crazy_filters_here).empty(raise="DoesNotExist").
> > latest()
>
> > Also, instead of:
>
> > from django.shortcuts import get_object_or_404
> > obj = get_object_or_404(SomeModel, **crazy_filters_here).latest()
>
> > you could do:
>
> > obj =
> > SomeModel.objects.filter(**crazy_filters_here).empty(raise="404").latest()
>
> > Another pattern that appears in my code is this:
>
> > try:
> > val =
> > SomeModel.objects.filter(**crazy_filters_here).values_list('val',
> > flat=True)[0]
> > except IndexError:
> > val = None
>
> > It should also allow this to work without raising an IndexError:
>
> > val =
> > SomeModel.objects.filter(**crazy_filters_here).empty(raise=None).values_lis
> > t('val',
> > flat=True)[0]
>
> > because empty() should return a NoneQuerySet or FourOhFourQuerySet or
> > something like that, which allows values() and slicing, but are
> > ignored.
>
> > I don't know, this is just an idea I had, what do you all think?
>
> > --
> > 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
> > athttp://groups.google.com/group/django-developers?hl=en.
>
> --
> live free or die;
--
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: [Proposal] Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py
Le 14 mars 2010 à 12:27, James Bennett a écrit : > On Fri, Mar 12, 2010 at 4:39 PM, aditya wrote: > >> Currently, Django uses "example.com" for both the domain and the >> name. The only way to change that is to wade into the actual >> database. > 2. If it turns out there's a real problem, provide a solution which > doesn't involve one-time settings and which, preferably, leverages > existing and proven features of Django rather than trying to add new > ones just for this case. Just my 2 cents, the "Django way" to deal with one-time settings is to ask directly the user (see admin user's creation) during the syncdb call. But, most of the time, I end up adding fixtures for the admin and launch syncdb with the --noinput option. Faster. That's a bit off-topic but this can lead to security issues given that your default fixtures will load whatever the environment. How do you handle this: fixtures by environment? Maybe we should reconsider the /sql/..sql pattern to add an environment info? Regards, David -- 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.
Tiny, tiny patch - can it make it into Django 1.2?
Hi, Just thought I'd ask whether or not http://code.djangoproject.com/ticket/10917 would be able to make it into Django 1.2? I know now is not the greatest time to ask, but it seems like a fairly tiny change that would help to make the new messages framework a lot more flexible when customising the admin site. Thanks, David -- David Reynolds da...@reynoldsfamily.org.uk -- 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: Tiny, tiny patch - can it make it into Django 1.2?
On 6 Apr 2010, at 19:54, Jacob Kaplan-Moss wrote: >> Just thought I'd ask whether or not >> http://code.djangoproject.com/ticket/10917 would be able to make it into >> Django 1.2? > > No. It's a feature addition, and we're well past feature freeze. No problem, just thought I'd ask. Sorry for the noise. Thanks, David -- David Reynolds da...@reynoldsfamily.org.uk -- 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: Front-End Developer - Contract/Telecommute | 40-50/hour
On Apr 7, 4:47 pm, OSS wrote: > Front-End Developer - Contract/Telecommute | 40-50/hour > > My client is a B2B media company and they are looking to hire a Front- > End Web Developer for a few upcoming projects, ranging from an online > publication development project to social media applications. This is > contract work for now, but it might have the potential to turn into a > permanent position for the right person. > > Here's a quick run down of the important stuff they are looking for, > ideally: > > * Solid JavaScript development experience. JQuery is a huge plus. > * Solid PHP experience. WordPress plug-in development would be great. > * Python experience would be a huge plus. Django experience an even > bigger plus. > * Solid HTML/CSS. This almost goes without saying. > * Experience working with templating languages would be great. > * Strong visual design skills. You should be able to craft amazing- > looking, functional user-interfaces even if you're not working off an > explicit mockup a designer has given you. > * The ability to learn and adapt quickly to new languages, APIs, > development requirements, etc. > > Above all else, what they require is a strong commitment to > productivity. They are not hiring somebody because their team lacks > the skill sets mentioned above; they are hiring somebody because they > have a lot of projects on their plate and they need to increase their > output. They are only interested in working with people who are > passionate about helping them increase the quality and quantity of > development work they do. > > Although my client has an office in NYC, your geographic U.S. location > is not important, since the development team is scattered around the > country. Wherever you live, you'll have to be comfortable working > with others remotely. You must be able to contribute as little as 20 > or as many as 40+ hours per week. > > To be considered, please submit your RESUME and HOURLY requirements to > beau[AT]open-source-staffing.com > > Thank you, > Beau J. Gould > -- > Open Source > Staffinghttp://www.open-source-staffing.comhttp://www.facebook.com/beau.gould > beau[AT]open-source-staffing.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: Pass Thru Image Proxy Patch Interest?
> Yes, I was thinking the other day that it would be a cool solution for
> serve() to be able to use storage backends
Wouldn't it be better to have some {% serve path/to/file %} template
tags, that does all the work of checking where the file exists and
returning the right URL? Putting this into serve() always means a
request to your local webserver which may lead to a HTTP-redirect (so we
have two requests).
Of course having a template tags means {{ MEDIA_URL }}path/to/file must
be replaced everywhere in your templates. But I think it's worth the
benefit.
Greetings, David Danier
--
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: High Level Discussion about the Future of Django
I just want to throw my 2 cents into the ring here. I'm not against a fork, but at the same time I want to see the Django mainline progress. However, let me tell you my story, and how I've seen the Django development process over the years. I started with Django 4 years ago. It was cool, shiny, and let us get up and running. At the time, were were one of the largest Django installations. We had needs, and some of those needs were met. However, many were not. We were the only ones furiously trying to get the core team to accept our patches, ideas, etc.. Now while I'm not going to say every idea we had was right for Django, there were in fact many that were great, and eventually have made it into trunk. There are also still many (lets take the classic #17 here), that still haven't made it into trunk, even though people have been even more aggressively pushing them lately. I honestly can only remember a single patch that I've committed that has ever been fully integrated into trunk (select_related refactor). Now, the development process has changed with Django over the years, but I will sadly say that I feel it's been for the worst. I've completely given up on trac, submitting patches, or even participating. Now while some may not like my aggressive tacts (e.g. James) that doesn't mean what I've brought to the table hasn't been needed. For the last year or two all I've seen on the trac whenever I took up the time to write a patch, or even submit a ticket, was a closure of "wontfix" for some, honestly, stupid reason. It just isnt worth my time to submit the same ticket 3 times just so its "correct", or it fits everyones needs. Tickets are not patches, and they shouldn't be treated like "if this one isnt accepted, create a new one". I think there's a split within the Django core team right now and I strongly believe that unless you can tirelessly convince a core developer (no matter how large the following), a feature is not going to make it into mainline. This to me is a serious issue when you're talking about an open source, community contributed project. Sure, the core team does a large amount of the work, but not without help from the community. I'll take this back to my old analogy, not everyone is building a blog, and if they are, they can go use WordPress. Many, many things have gone ignored for far too long. I love Malcom's ORM refactor, but that was at a standstill for I don't know how long, and that entire time any patch which was related to improvements to the ORM was ignored simply stating "we're working on a refactor of the ORM". This philosophy seems to continue still today. Just recently there was a post about "High Level Talk About Django" (or whatever it was called). Now while the thread didn't make a whole lot of sense in general, it was just an attempt to gather some ideas, and brainstorm. Immediately it was shut down by the core developers. What frustrates me even more is all of this pony talk. If there's one thing I dislike it's Django's philosophy that "if it can be done 3rd party, do it", yet even the simplest things, like the template engine, have better 3rd party implementations (Jinja2). Django still doesn't have migrations. It still doesn't have dependancies. It's seriously lacking in many areas which other (albeit lesser) alternatives such as Rails have made available for far too long. Now while there's great 3rd party apps for things like this (South), and there's a few mediocre sites to find pieces of code (Django Snippets), this doesn't solve the problem which is really going on in Django: The community cant contribute beyond what the core team deems necessary. For me, I've entirely given up on trying to give back to Django. I've written enormous amounts of questionable code simply so I didn't have to patch Django, or even bother dealing w/ the process of Django's development. Monkey patching, ugly metaclass hacks, you name it. Anything that's made it easier to avoid this "process", has made it easier for us to develop. I continue to build these "ponies", but that doesn't make them any easier to integrate in Django. All in all, I think some things have been ignored for far too long. Simple things, again, like migrations, JSON and RESTful utilities, and even the tools to make development easier (the debug toolbar hasn't been around that long). Yet so much time is spent on things like refactoring the admin (while it's useful, in the big picture, its not flexible, and never can be), the template system, and many other things which have been done and done again by other people. Again, this is just my opinion, and I do know that many share it. This has been one of the largest outcries of people I've seen in a while. I honestly can't see that I see a fork succeeding, but I would definitely like to see what can happen to make the "process" friendlier to people like myself and some of the others who have posted here. Really, for me, I just don't (nor do I want to) have the time to
Re: Process discussion: reboot
On Mon, Apr 19, 2010 at 11:31 AM, Jacob Kaplan-Moss wrote: > On Mon, Apr 19, 2010 at 10:19 AM, orokusaki wrote: >> The release of Django 1.0 comes with a promise of API stability and >> forwards-compatibility. In a nutshell, this means that code you >> develop against Django 1.0 will continue to work against 1.1 >> unchanged, and you should need to make only minor changes for the 1.2 >> release. > > So you're proposing that 1.2 be the last backwards-compatible release, > and that 1.3 be incompatible (if necessary) with 1.2? I think he's saying that 1.3 will work with 1.2 but not (necessarily) with 1.1, and 1.2 will work with 1.1 but not (necessarily) with 1.0. The specific number of point releases to remain compatible with can probably be quibbled over, but I think the point is that maintaining across the entirety of 1.x releases when point releases take this long can be untenable for good forward momentum. -- dz -- 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: Process discussion: reboot
On Mon, Apr 19, 2010 at 12:14 PM, Jacob Kaplan-Moss wrote: > On Mon, Apr 19, 2010 at 10:38 AM, David Zhou wrote: >> The specific number of point releases to remain compatible with can >> probably be quibbled over, but I think the point is that maintaining >> across the entirety of 1.x releases when point releases take this long >> can be untenable for good forward momentum. > > I'm pretty annoyed that you think that the policy is to maintain > backwards compatibility "across the entirety of 1.x releases" because, > well, that's not the policy. This is documented; see > http://docs.djangoproject.com/en/dev/internals/release-process/. You're right, of course, and I should've fact checked orokusaki's assertion that that was the current policy. So I'll retract my previous statements -- those are only applicable given the policy stated in orokusaki's email. -- dz -- 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: Cross-field Model Validation and Ticket #13100 (Was: Re: High Level Discussion about the Future of Django)
Realizing my original statement I was regarding this thread, in this thread, it's obvious that this has gone completely off track. I might have to take back everything I thought about this being useful. If you want to address a SPECIFIC concern, it makes sense to do that under its own topic. Think of this mailing list like a forum, as, after all, many of us browse it just like one. When a "thread" happens to have 12 different topics it loses its value fast. On Apr 19, 3:44 pm, Richard Laager wrote: > In the end, *my* requirement is that I have *some place* to put > validation code that 1) can see the whole model instance, 2) will be run > from the admin interface, and 3) will return nice validation failures to > the user (not throw exceptions that will give the user a 500 error and > send me an email). > > A) Is this an unreasonable pony? If so, why? > B) If not, how can I implement this such that it will get accepted? > > I'd like to have it in for 1.2 if possible, as the model validation > interfaces are new. Once released, there will be more > backwards-compatibility guarantees to maintain. > > > > > > On Mon, 2010-04-19 at 10:53 -0500, James Bennett wrote: > > On Mon, Apr 19, 2010 at 10:16 AM, Richard Laager wrote: > > > On Mon, 2010-04-19 at 07:55 -0700, orokusaki wrote: > > >> With all respect, you still haven't addressed my main concern: You > > >> told me that it was because of backward compatibility that this simple > > >> change couldn't be put in the trunk. It is backward compatible. If I'm > > >> wrong, it would suffice to have a simple explanation of what it > > >> breaks. > > > > I'd like to second this question. orokusaki suggested a couple of things > > > in ticket #13100, but I'm seconding specifically this comment: > > >http://code.djangoproject.com/ticket/13100#comment:8 > > > The difference between how ModelForm works and how Model works is > > that, if you're overriding clean() on a ModelForm subclass, you don't > > automatically get uniqueness validation -- you have to call up to the > > parent clean(), or manually apply the uniqueness validation in your > > own clean(). > > Thank you for this explanation. > > orokusaki noted in ticket #13100: > "The only difference between its implementation and > ModelForm?._post_clean() is the internal check it makes before running > validate_unique()." > > So is the actual issue here that naively calling Model.full_clean() will > always run Model.validate_unique(), when the existing > ModelForm._post_clean() code only calls Model.validate_unique() when > self._validate_unique? > > If so, Model.full_clean() is new in 1.2. So, could we just add a kwarg > like this (or similar)? > def full_clean(self, exclude=None, validate_unique=True) > > Then, it would be modified to only call Model.validate_unique if the > validate_unique argument was True. > > Then, you could call Model.full_clean() from ModelForm._post_clean(), > passing self._validate_unique and preserve the same behavior. > > Alternatively, could we add another function to Model that allows for > whole-model validation but does not call Model.validate_unique() and > then call that from ModelForm._post_clean() instead of calling > Model.full_clean()? Of course, Model.full_clean() would have to call > this new validation function as well. > > Richard > > -- > 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 > athttp://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: Class based generic views in 1.3?
Le 12 mai 2010 à 22:16, Ben Firshman a écrit : > > On 11 May 2010, at 01:37, Russell Keith-Magee wrote: >> >> >> Are class-based views planned for 1.3? Well, we haven't done any >> formal planning for 1.3 yet, but I'm going to guess that the 1.3 high >> priority feature list will essentially be "the features that got >> dropped from 1.2", so in all likelihood, yes. However, that doesn't >> mean that they will definitely be in 1.3 - someone still needs to do >> the implementation. If you really want class based generic views, be >> like Ben and make it happen -- show us the code!. > > Oooh, class-based views. > > This is something I've been thinking about a lot, and I'll probably dive into > it at the Djangocon.eu sprints. Feel free to make a start Jari. ;) I'd love to sprint on this at EDC too. Regards, David -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Class based generic views in 1.3?
Hello, We're working on this with Ben during djangocon.eu sprint [1]. Any comment appreciated, still a work in progress though. Regards, David [1] http://github.com/bfirsh/django-class-based-views -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Class based generic views in 1.3?
Le 28 mai 2010 à 00:01, Luke Plant a écrit : > On Thursday 27 May 2010 17:29:28 David Larlet wrote: >> Hello, >> >> We're working on this with Ben during djangocon.eu sprint [1]. Any >> comment appreciated, still a work in progress though. > > Looks cool. I think Jari's idea of a class method to instantiate the > classes would be a great pattern to establish - something like an > 'as_view' classmethod on the base class which returns a view function > that uses the class: > >@classmethod >def as_view(cls, *initargs, **initkwargs): >def view(*args, **kwargs): >obj = cls(*initargs, **initkwargs) >return obj(*args, **kwargs) >return view > > The developer can choose whether to write 'MyClassView.as_view()' > directly into the URLconf, or put a line into views.py like 'my_view = > MyClassView.as_view()' > > This will solve the thread safety issue, and doesn't require another > import for a decorator, as Jari pointed out. > > We could decide whether to apply decorators inside as_view() or > __call__(). The argument for putting it in 'as_view' is that __call__ > does some processing that you might want to skip entirely (e.g. the > get_object() call - if we applied a 'cache_page' decorator, we > wouldn't want the get_object() call to be made at all if there was a > cache hit). We discussed that point with Jacob and it looks like it's easier to modify urlresolvers to create a new instance of the class when we detect it's a class, this should solve the thread safety issue. Do you see any drawback to this approach? That way we can declare decorators via a decorators' list [1] or directly in the class [2]. I'm not fond of the second way, decorating a decorator, but we can create decorators dedicated to class based views easily that way. > > On that point, I think 'GenericView' should be split into 'ClassView' > and 'GenericView'. The get_object() call is probably not a good thing > to have on a base class. Agreed, I'll make that change. Thanks, David [1] http://github.com/bfirsh/django-class-based-views/blob/master/class_based_views/tests/views.py#L24 [2] http://github.com/bfirsh/django-class-based-views/blob/master/class_based_views/tests/views.py#L43 -- 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.
Feature request: coalesce for aggregates
I would love to see the aggregate classes (Sum, Avg, etc) take an
optional second parameter that becomes the value in a coalesce
statement in the resulting query. Basically, this would function a
lot like dict.get. Right now the only option is to resolve to None.
If, for instance, you could say Sum('foo', 0), it would turn into
COALESCE("foo", 0) as "foo__sum" and result in a return of
{'foo__sum': 0} where no matching records with non-null values for
column "foo" were fetched by the query.
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: Logging in Django
On 28/05/2010 16:48, Russell Keith-Magee wrote: The second commit will be the addition of actual logging. The intention here is to be initially conservative; two immediate targets would be to replace calls to mail_admins() with logging calls, and replacing debug messages in management commands with their logging equivalent. At this point, it largely becomes a political problem -- we don't want Django's core to get bogged down in trivial logging calls, so we need to develop our policy on when we add a logging statement to trunk, and at what trace level, and so on. How about not adding any logging statements to trunk directly at all? Static logging is in some ways bad: * There's no central control over the formatting of log statements * They have to be sprinkled all over the place (or in a lot of places, at least) rather than the logging aspect of the application being more centrally defined, which makes it hard to ensure they're consistently where they ought to be One way round this is to use an aspect-oriented approach, which is nice and easy in Python - e.g. http://www.hackersinshape.net/archives/67 - this would allow us to drop decorators onto functions we want logging around, and possibly even do so dynamically for maximum flexibility and ease of maintenance. Of course, the end result would still be calls to the standard logging framework, so this suggestion is entirely orthogonal to the rest of the proposal. Just my €0.02, anyway. If the consensus is that there's some mileage in the above I might be willing to try and come up with some code, though my time is limited. Equally, I'm sure some of you may have been thinking along these lines already :-) Cheers, David -- 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: Proposal: Revised form rendering
Hi,
Le 11 juil. 2010 à 17:36, Russell Keith-Magee a écrit :
> I'd like to propose a few extensions to Django's form library for 1.3.
First of all, thanks or your proposal, the current form rendering is the worst
part of Django to me and I'd like to help to improve that in 1.3.
> Layout
> --
> style, we can get that by simply loading a different renderer that
> implements that style:
>
> {% load custom_renderer %}
> {% form myform %}
>
> Django would ship with {% form %} implementations of the 'as_p' and
> 'as_ul' strategies, so getting 'as_p' rendering would mean:
>
> {% load xhtml_p_forms %}
> {% form myform %}
Just a personal feedback, to me the rendering strategy is related to a whole
project and should be defined in settings, it's too easy to forget a loading in
a template. I know that you can use the django.template.add_to_builtins
function but it in this case it should be documented.
>
> Widgets
> ---
>
> Chrome can also be parameterized; for example:
>
> {% form myform field name using autocomplete:"name_autocomplete" %}
>
> might define a chrome that implements an Ajax autocomplete widget
> using the named URL "name_autocomplete" as a data source. This has to
> potential to start giving an answer to the "Why doesn't Django do
> AJAX" monkey; Django won't provide an AJAX solution out of the box,
> but packaging a chrome that implements AJAX should be a lot easier.
If it requires an extra {% form %} arg it will not be that easier if you need
to override all third-party apps' templates. Note that I haven't got any
solution, that's more to bring the discussion on that topic :-).
>
> Doctypes
>
>
> Once these two changes are in place, we use the form template tag
> specify the doctype that is passed to the widget render call. A
> 'html5_p_forms' library will pass 'html5' as the doctype when
> rendering fields, and get HTML5-compliant form fields; the
> 'xhml1_p_forms' library will pass 'xhtml1', and get XHMTL1-compliant
> form fields.
Again, why not directly in settings in order to be project's specific? Is there
anybody mixing doctypes on the same website? (backward compatibility maybe?)
Regards,
David
--
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: Could not import man.credit.views, python 2.6.5. "No module named dl" error
It's an import issue with your app unrelated to django core. Someone here will eventually tell you to direct that to django-users, so you might as well hop over there now. On Jul 12, 4:31 pm, pacman wrote: > Hi, > > I've upgraded our python from 2.4 to 2.6.5. When connecting to django > server (1.2.1), it shows the following error: > > I assume it's still searching for deprecated dlmodule.so (py 2.4) or > dl.so (py 2.6). We didn't compile that module in py 2.6.5. Anyone has > seen this error and knows fix on the django side? Thanks! > > TemplateSyntaxError at / > Caught ViewDoesNotExist while rendering: Could not import > man.credit.views. Error was: No module named dlRequest Method: GET > Request URL:http://devpmmtg1:9060/ > Django Version: 1.2.1 > Exception Type: TemplateSyntaxError > Exception Value: Caught ViewDoesNotExist while rendering: Could not > import man.credit.views. Error was: No module named dl > Exception Location: /usr/local/python-2.6.5/lib/python2.6/site- > packages/django/core/urlresolvers.py in _get_callback, line 132 > Python Executable: /appl/pm/vendor/python/lx-x86/python-2.6.5/bin/ > python > Python Version: 2.6.5 -- 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: firebird backend for django
Hi,
I've opened a ticket for months ago -
http://code.djangoproject.com/ticket/13159.
Only needs a test case.
David Elias
On Jul 23, 10:30 pm, maxi wrote:
> Hi,
>
> I'm working on django-firebird project and doing some modifications
> for work with django 1.2
> Right now, I'm trying to pass some tests running the tests suit of
> django trunk code and I found the next problem:
>
> django is trying to execute this sql:
>
> SELECT "AGGREGATION_BOOK"."PRICE", COUNT("AGGREGATION_BOOK"."PRICE")
> AS "COUNT"
> FROM "AGGREGATION_BOOK"
> GROUP BY "AGGREGATION_BOOK"."PRICE"
> ORDER BY count DESC, "AGGREGATION_BOOK"."PRICE" ASC
>
> But, I get the next error:
>
> DatabaseError: (-104, 'isc_dsql_prepare: \n Dynamic SQL Error\n SQL
> error code = -104\n Token unknown - line 1, column 157\n DESC --
> SELECT "AGGREGATION_BOOK"."PRICE", COUNT("AGGREGATION_BOOK"."PRICE")
> AS "COUNT" FROM "AGGREGATION_BOOK" GROUP BY "AGGREGATION_BOOK"."PRICE"
> ORDER BY count DESC, "AGGREGATION_BOOK"."PRICE" ASC')
>
> The problem is with the count field on ORDER BY clause. The sql is
> defined as COUNT("AGGREGATION_BOOK"."PRICE") AS "COUNT" and the
> count field is upper case (and quoted) then the order by clause must
> be:
>
> ORDER BY "COUNT" DESC
>
> Which method can I override to solve this?
> Any help?
>
> Thanks in advance.
>
> Maxi.
--
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: Patch and tests for #13182
Noted... sorry about the spam in that case :) D On Aug 6, 10:52 am, Russell Keith-Magee wrote: > On Fri, Aug 6, 2010 at 8:31 AM, David P. Novakovic > > wrote: > >http://code.djangoproject.com/ticket/13182 > > Let me know if there is anything else I can do on this ticket, it is fairly > > simple anyway. > > Hi David, > > Thanks for the patch submissions, but you don't need to send a message > to django-dev every time you upload a patch on a ticket. > > The django-updates mailing list gets notified every time a ticket in > Trac is updated, and most of the core team are subscribers to that > list. On top of that, Trac is ultimately a better source of data on > this, because it is much easier to search. > > There are two exceptions to this general rule: > > 1) You've fixed a bunch of tickets in a related area (e.g., 6 tickets > on bugs in select_related()). This makes a nice target for core > developer attention. It takes time to "spin up" on a given area of > code, especially in a complex area like the internals of the query > engine. If you can provide a bunch of tickets in the same area, it > means the 'cost' of spinning up can be spread over multiple tickets. > > 2) You've done some work on a particular ticket, but you haven't had > any response/review for a while. In this case, a gentle nudge/request > for review can help to grease the wheels. Again, if you have multiple > tickets, this makes the task more attractive. > > Please keep up the good work! > > 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: Model translation
your model it will rewrite
calls to filter/order_by() to use the right field:
filter(name='...') -> filter(name_xx='...')
filter(name__contains='...') -> filter(name_xx__contains='...')
order_by('name') -> order_by('name_xx')
...models.Q-filters do not work of course
These apps are as simple as I could implement them, but they both helped
me a lot more than any other full blown solution. This is why I think we
should create better tools for doing such things inside Django instead
of trying to provide a solution to solve everything.
I hope I haven't missed something essential. Model translations really
touches most of the parts of Django (urls.py, QuerySet, views and of
course models). I intentionally have left out some aspects, because they
are not relevant to most users (for example translated content and full
text search (haystack)).
Thanks for reading this far,
David Danier
--
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 1.3 and Python 2.4
On Wed, 2010-08-11 at 14:48 +0200, Dennis Kaarsemaker wrote: > On Wed, Aug 11, 2010 at 2:20 AM, Russell Keith-Magee > wrote: > > > Like it or not, RHEL is still a major player in the enterprise market > > at the moment. I can't speak for the US, but in Australia at least -- > > when all those companies got on the Linux bandwagon in the mid 2000's, > > they all adopted RHEL, and being large enterprises, they aren't moving > > away from that platform in a hurry. I don't particularly want to rush > > this segment of Django's market share into the arms of another > > framework. > > > > I'd rather defer dropping support for Python 2.4 until Django 1.4; > > that way, we can use the 1.3 release notes to draw attention to the > > impending deprecation. > > > > On top of that, RHEL5 moves into support mode (production 2) at the > > end of Q1 2011, and into long-term support mode (production 3) in Q1 > > 2012. A Django 1.4 release would roughly coincide with the start of > > support mode. Also, by that time, RHEL6 will hopefully be out, > > hopefully providing a more recent Python release as a baseline, which > > will provide a way forward for those with support contracts. FWIW I've built an unofficial python 2.6 for RHEL5 as part of "EPEL" [1] to try to ease the transition. If you're using EPEL5, then: yum install python26 should get you the interpreter, "python26-devel" for building extensions, etc. This is parallel-installable with the main python 2.4 runtime. A (very small) stack of prebuilt rpms against python26 is also available [2]. Let me know if there are other dependencies you need. This is a personal side-project of mine, and is not officially supported by Red Hat. Hope this is helpful Dave [1] http://fedoraproject.org/wiki/EPEL [2] https://bugzilla.redhat.com/showdependencytree.cgi?id=573151&hide_resolved=0 (snip) -- 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.
Some thoughts about the new settings.configure() and decoupling
I think one way to go is with factories. The packages don't know nothing where settings coming from. These settings are passed within a constructor or something and django would use factories that know to look from django.conf.settings and passed them to the new object. Although i don't get it yet, i think dependency injection (http://www.martinfowler.com/articles/injection.html) could be a possible solution :-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Some thoughts about the new settings.configure() and decoupling
Malcolm Tredinnick wrote: > Hi David, > > On Mon, 2006-05-22 at 15:06 -0700, David Elias wrote: > > I think one way to go is with factories. > > The packages don't know nothing where settings coming from. These > > settings are passed within a constructor or something and django would > > use factories that know to look from django.conf.settings and passed > > them to the new object. > > That is precisely how it is currently implemented, in effect. Although > it's not a completely plain "factory function", when you first access > django.conf.settings or call configure(), it sets up the right > settings-producing class that is used on all subsequent uses of > django.conf.settings. It's not what a Computer Science student might > immediately identify as a factory function from the shape of the code, > but it is doing the same thing. > > And if, for some reason, you wanted to override the settings "producer", > dropping a new implementation of UserSettingsHolder into django.conf is > not too hard either (not documented, since there should be almost no > reason for it and it's not that hard to read the code if you need to). > Something like > > from django import conf > > conf.UserSettingsHolder = MyUserSettingsHolder > conf.settings.configure(...) > > will work if you do it before anything else accesses the settings. > > > > Although i don't get it yet, i think dependency injection > > (http://www.martinfowler.com/articles/injection.html) could be a > > possible solution :-) > > I'm not entirely sure what you are suggesting here. How does this help > with the usage of this feature (which I assume is what you're talking > about)? At some point, you still have to tell Django what the values for > your particular set of configuration variables are. Or use the defaults. > The configure() function provides that functionality at the moment. > > I'm really not sure what pieces you are trying to "decouple" here. > Things like the templating system and ORM need configuration settings. > Some some infrastructure is required. Omitting anything from under > django.conf entirely would not really save lines of code overall. And > the usage API seems about as minimal as you can get (set what you need, > use default for the rest). So can you explain you thinking further? Hi there, I was thinking in way to remove lines like this from django.conf import settings from the template system and ORM, something like passing the desireable settings within the constructor, or something. About the factories i was not mention the one of django.conf, i was thinking in factories that belongs to django and not to the template system or ORM. Right now i don't have some code to demonstrate, i'm also writing a firebird backend so i'm learning how the frameworks works as well. > > Malcolm --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Issues on making the firebird backend working
Hi there,
I've started working on firebird's backend and Adrian is also
refactoring for the oracle support, so it's a good time to discuss this
:)
First, field and constraint names can't be bigger than 31 chars.
In the creation.py declared for PositiveIntegerField
integer CHECK("%(column)s" >= 0)
NOT NULL must be declared first than the CHECK.
Declaring NULL is invalid must be DEFAULT NULL.
The LIMIT, OFFSET problem like oracle.
Perhaps to fix this some sort of default functions could be defined in
django.db.backend or django.db.schema which backend could overwrite or
not.
Another thing is if it could be created something like
"pre_create_table" and "post_create_table" with the dispatcher
framework to create triggers, sequences, domains etc, thoughts?
I'm a python and firebird newbie so i could missing something .. if are
any django and firebird devs out there some sort of help would be nice
:)
David
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: Issues on making the firebird backend working
Well, AS in FROM clause is not support... Thoughts, ideas...? I think we're not going to have Firebird support in Django :p --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Issues on making the firebird backend working
Michael Radziej wrote: > David Elias wrote: > > Well, AS in FROM clause is not support... > > Not even in the equivalent form > > SELECT ... FROM table_name alias > > ? > > That would really suck. How do you do joins to "self" then? > > Michael With all the work i've forgot that, made a simple test and worked, thanks! Already have admin app working, i'm going to test removing AS. David --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Issues on making the firebird backend working
Adrian Holovaty wrote:
> On 6/1/06, David Elias <[EMAIL PROTECTED]> wrote:
> >
> > Well, AS in FROM clause is not support...
> >
> > Thoughts, ideas...?
>
> Hey David,
>
> Sorry for the slow response -- let's take each issue one at a time.
> What do you have coded so far?
>
> Adrian
>
> --
> Adrian Holovaty
> holovaty.com | djangoproject.com
Hi,
I have made some nasty changes in management.py for quick testing,
removed "referencing" when creating contraints, but that will not
resolve the column name size limit. Changed NULL to DEFAULT NULL.
Firebird suffers from the same problem as Mysql concerning date/time
fields, it doens't accept the microseconds, so i've changed in
fields/__init__.py
I've also changed models/base.py in save method:
backend.add_limit_offset_sql("SELECT 1 FROM %s WHERE %s=%%s", 1)
So far sessions are working :)
David
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: Issues on making the firebird backend working
I've got the backend's base, create and introspection almost done. Should i create a ticket or use this one http://code.djangoproject.com/ticket/1261 and attach the files? David --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Issues on making the firebird backend working
Already added the patch, for the ones that didn't know - http://code.djangoproject.com/ticket/1261 I'm trying to remove the "if settings.DATABASE_ENGINE == 'firebird'" from management.py and add some signals to use with the dispatcher. Already got this working inside the function "get_sql_create(app)" sending post_sql_create signal and connecting to this signal in the creation module, modifying the final_ouput. Adrian, assuming that you are working on database support, are any plans that each backend may add sql statements to the sqlall output in the future? ps: sorry for my english David --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Multiple database support (#1142) roadblock
[EMAIL PROTECTED] wrote: > perhaps we could put it all into backend/creation.py. That's what i had, early, implemented with the firebird backend patch, put the sequence and triggers sql in creation.py. And now i was trying retain the management.py intact in terms of functionality, but your aproach in puting all the sql statements in creation module is better, i think. At least will give much more flexibility for generating SQL for all backends. Nice work. David --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
urlify.js blocks out non-English chars - 2nd try?
Hi all, I've recently added an enhancement (ticket #2282) about urlify without checking for duplicate and there is already a proposal (my mistake) and a discussion on this mailing-list which were unfortunatly closed now: http://groups.google.com/group/django-developers/browse_thread/thread/cecdf42cb3430601/1a53ee84c1742b1e I'd like to know if it's possible to do something about it? What are previous conclusions and facts since the last discussion? I'm new in Django and I may help in Python but not in js so I need your help ;). My current problem is for french accents so it's not really difficult (I've pasted a js from a french blog app on my ticket) but I'm conscious there are more problems with other languages. Concerning utf-8 URLs, I don't know if it's really a good idea because this is actually associated to phishing... Cheers, David Larlet --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Suggestion for #1602, urlify.js blocks out non-English chars [was urlify.js blocks out...]
2006/7/12, Bill de hÓra <[EMAIL PROTECTED]>: > > Malcolm Tredinnick wrote: > > > Personally, I was kind of hoping whoever wrote > > the patch might think this sort of thing through and give us a concrete > > target to throw ideas at. :-) > > Hi Malcolm, > > Here we go: > > [snip] > > > I need to test this properly and fill in the mappings, but the gist of > the approach should be clear. When that's done, unless someone has an > objection, I'll file a patch against > >http://code.djangoproject.com/ticket/1602 >(also 2282) > . > Hi, Thanks for your job, seems good to me but what about the size of the final urlify.js? I'm afraid that it will increase a lot and maybe the current one is good for most of the cases, is it possible to easily switch between the two for english writers? Another question is about customisation of removelist. What's your opinion about that? Cheers, David --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Slides of Europython 2006?
Hi! I'd like to know if it's possible to have access to django slides of Simon's conf at Europython 2006. Maybe I haven't found those but there are not listed on the official page: http://indico.cern.ch/sessionDisplay.py?sessionId=9&confId=44 Cheers, David Larlet --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Slides of Europython 2006?
2006/7/19, Simon Willison <[EMAIL PROTECTED]>: > > > On 19 Jul 2006, at 15:43, David Larlet wrote: > > > I'd like to know if it's possible to have access to django slides of > > Simon's conf at Europython 2006. > > I've uploaded my slides to the conference site: > > http://indico.cern.ch/contributionDisplay.py? > contribId=26&sessionId=9&confId=44 > > They're a 22 MB PDF file. > Thanks a lot, I'd like to present django to my company ;) Cheers, David --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Model inheritance API
Jacob Kaplan-Moss wrote: > On Jul 22, 2006, at 9:37 PM, Malcolm Tredinnick wrote: > > Rather than watch the "inherit from User" thread go round and round, > > maybe I should give people something more concrete to think about. First of all, +1 on this proposal. I've been approaching this problem from different ways for the past couple of weeks, and had settled on a very similar one to implement myself. I was suffering from a lack of examples of how to use the content type app though. > > (2) Any strong reason not to include this case? It's only for > > "advanced > > use", since there are a few ways to shoot yourself in the foot (e.g. > > declare a class abstract, create the tables, remove the abstract > > declaration, watch code explode). However, it will be useful in some > > cases. [I have some scripts to help with converting non-abstract > > inheritance to abstract and vice-versa at the database level, too.] > > I think abstract base classes are *key*, actually -- nearly every use > I'm thinking of includes 'em. . . . > So I'd get back an iterator that yields Things, Animals, and Toys? > That's what I'd expect, and want. I also think keeping the abstract class as a way of aggregating all the subclasses is key. An iterator is exactly what I would like to see as well. Please post any examples / code as they come! David Blewett --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
ImportError: No module named __future__
Mod_python error: "PythonHandler django.core.handlers.modpython" Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 287, in HandlerDispatch log=debug) File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 457, in import_module module = imp.load_module(mname, f, p, d) File "/home/django/django/core/handlers/modpython.py", line 1, in ? from django.core.handlers.base import BaseHandler File "/home/django/django/core/handlers/base.py", line 2, in ? from django.dispatch import dispatcher File "/home/django/django/dispatch/dispatcher.py", line 28, in ? from __future__ import generators ImportError: No module named __future__ I've setup Django before without major problems, but I'm setting it up on another personal server, and for some reason this time I get this error message. when the httpd.conf -> PythonPath has sys.path included, it can only be included by putting it in the single quotes as such 'sys.path', When I add it assys.path + it tells me it can't find the django module. Any ideas? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Trac and Akismet rejected spam
I'd like to update the french translations urls in http://code.djangoproject.com/wiki/TranslateDocumentation with this new content : http://vrac.biologeek.com/askimet_error.txt and I get an Askimet rejected spam error. So, how can I do to update this page? Regards, David --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Dynamic Menus...
Hey! I saw you on a Google video! I feel like I'm talking to a celeb! :-) --Dave Jacob Kaplan-Moss wrote: On Aug 24, 2006, at 2:14 PM, mediumgrade wrote: Don't know if this is a Django question or not, but here is the situation: I am developing an application for a client who is a automobile broker. He wants agents to submit requests for vehicles from the web. The agent will be able to select the make/model of the vehicle. What I want is for the model menus to adjust dynamically depending on the make selected. For example, if the agent selects "Honda" I only the the models menu to show Civic, Accord, Element, ect. How can this be achieved? It's pretty much a _javascript_ thing; googling around for "_javascript_ select" or "dynamic select" should find something useful. FYI, you're likely to get much better responses if you post questions of this nature to django-users. django-developers is where we discuss developing Django itself; django-users is for questions about using Django. Thanks! Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Integrating Django and SQLAlchemy
Robin Munn wrote: > The notes on implementation that Adrian posted pretty much match what > I'm thinking at this point. The plan is to make this 100% API > compatible (if possible -- you never know what will turn up once you > start implementing some idea), so that existing code doesn't need to > change. But if you want access to the underlying SQLAlchemy objects to > do something like a nine-table query involving five LEFT OUTER JOINs > and two subselects, well, you should be able to do that as well. Indeed great news!! At work i am trying to build the Django ORM on the top of SQLAlchemy core. I've tried on the top of the ORM but it was overkill, but i could had done something wrong. I was getting about ~10 request per second oposed to ~50 request per second with firebird. Are you planning to build the integration on the top of the SQLAlchemy ORM? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Google Sitemaps
On 8/30/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: My only quibble is the recommendation in the docs to call``ping_google()`` from the ``save()`` method. I think the idea ofsetting off a HTTP request from within a ``save()`` method isn't sucha grand idea; network latency could cause the save to take too long, or the request could raise an exception causing the object not to getsaved... I'm not sure about what would be better, but it does rub methe wrong way.What about using signals? The ping_google() call could be activated by hooking in to the post_save() signal. David Blewett --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
spamblocked ticket: Use IPython profile if in current directory
"Akismet rejected spam", so, though very minor, here's my ticket.
=== Use IPython profile if in current directory ===
[http://ipython.scipy.org/ IPython] is great. It's profiles are very nice and
it would be neat to use one if available.
This patch offers a way to do that. It assumes that any file in the current
working directory that starts with ipythonrc- is an IPython profile and tells
IPython to use the first 1 found.
Of course you could just have a go.py script in the same directory and always
%run go.py as your 1st command.
Did I mention IPython is great?
Priority: lowest
Component: django-admin.py
Severity: trivial
Patch follows:
Index: core/management.py
===
--- core/management.py (revision 3918)
+++ core/management.py (working copy)
@@ -1170,10 +1170,14 @@
if use_plain:
# Don't bother loading IPython, because the user wants plain
Python.
raise ImportError
-import IPython
-# Explicitly pass an empty list as arguments, because otherwise IPython
+import IPython, glob
+# Explicitly pass a list as arguments, because otherwise IPython
# would use sys.argv from this script.
-shell = IPython.Shell.IPShell(argv=[])
+try:
+argv = ['-profile',
glob.glob("ipythonrc-*")[0][10:].replace('.ini','')]
+except:
+argv = []
+shell = IPython.Shell.IPShell(argv=argv)
shell.mainloop()
except ImportError:
import code
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: Spamblocked ticket: #2282 (Urlify in admin compatible with accents)
2006/10/27, orestis <[EMAIL PROTECTED]>: > > Here's a thought: > > Can't every language have its own urlify.js file ? Like urlify.fr.js, > urlify.el.js, urlify.de.js etc. Django selects the correct one by > looking at the Locale settings, or falls back at the default (English) > one if there isn't any. > Yes, I think it could be a good solution, I can do the urlify.fr.js file. Cheers, David --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Branch Merges?
I would like to suggest that the branches that are felt to be complete sans testing be merged into a single branch. I am anxiously awaiting several different branch merges to core but do not have time to check each individual one out to test them. Maybe it's time to begin a larger effort, similar to magic-removal, at merging all these branches? David Blewett --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Branch Merges?
James Bennett wrote: > So let me reiterate the call for anyone who wants to bang on a branch > to step up; we'll set you up with access to commit code and let you > bang away on it to your heart's content :) Sounds good to me. What do we need to do here? I'd like to help out with the FullHistory branch. It looks like it hasn't had trunk merged to it in a while. David Blewett --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: psyucopg2 status
Gary Doades wrote: > Yeah, I've been using it for a couple of months now with no problems. I > also use it on another project via SQLAlchemy. > > I only really pointed it out when I saw the beta chapters (chapter 2) > for the book. If it still recommends psycopg1 when it comes out it may > look out of date. > Just wanted to jump on the band wagon. I've been using psycopg2 for ~6 months now and haven't had an issue with it. I think this is a really valid point. We all know things are out of date as soon as they're printed, but this would be a real shame to be in the book. David --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Fwd: how are you handling i18n and m10l content?
> > Actually this could be integrated into the core.
> > When you create a model, you could add translatable=True to fields
> > that have to be in the language-specific table.
> > When you make selections, you would need to set the language name in
> > the following or a similar way:
> > MyModel.objects.by_language("EN").all()
> > MyModel.objects.by_language("EN").order_by('title')
> > which would form queries like:
> > SELECT * FROM myapp_mymodel INNER JOIN myapp_mymodel_translatable ON
> > myapp_mymodel.id = myapp_mymodel_translatable.id ORDER BY title
>
> > Regards,
> > Aidas Bendoraitis [aka Archatas]
What about using generic relations for this? You could have something
like this:
class I18NText(models.Model):
language = models.ForeignKey(Language)
field = models.CharField(maxlength=25)
translated_text = models.TextField()
content_type = models.ForeignKey(ContentType)
object_id = models.PositiveIntegerField()
translated_object = models.GenericForeignKey()
def __str__(self):
return self.translated_text
class ModelNeedingTranslation(models.Model):
foo = models.IntegerField()
bar = models.TextField()
translations = models.GenericRelation(I18NText)
Then you can add translations of field(s) by doing:
a = ModelNeedingTranslation(1, 'nothing')
a.translations.create(field='bar', translated_text='nada',
language=Language('Spanish'))
You can get the text for a specific translation like this:
a.translations.filter(field='bar', language=Language('Spanish'))
David Blewett
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Fwd: how are you handling i18n and m10l content?
On Nov 9, 8:14 am, "David Blewett" <[EMAIL PROTECTED]> wrote:
> What about using generic relations for this? You could have something
> like this:
>
> class I18NText(models.Model):
> language = models.ForeignKey(Language)
> field = models.CharField(maxlength=25)
> translated_text = models.TextField()
>
> content_type = models.ForeignKey(ContentType)
> object_id = models.PositiveIntegerField()
> translated_object = models.GenericForeignKey()
>
> def __str__(self):
> return self.translated_text
>
> class ModelNeedingTranslation(models.Model):
> foo = models.IntegerField()
> bar = models.TextField()
>
> translations = models.GenericRelation(I18NText)
>
> Then you can add translations of field(s) by doing:
> a = ModelNeedingTranslation(1, 'nothing')
> a.translations.create(field='bar', translated_text='nada',
> language=Language('Spanish'))
>
> You can get the text for a specific translation like this:
> a.translations.filter(field='bar', language=Language('Spanish'))
>
> David Blewett
Here's some links about generic relations:
http://feh.holsman.net/articles/2006/06/19/django-generic-relations
http://www.djangoproject.com/documentation/models/generic_relations/
David Blewett
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
New firebird backend using the boulder-oracle-sprint branch
Please check http://code.djangoproject.com/ticket/1261 David Elias --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: New firebird backend using the boulder-oracle-sprint branch
Make sure you are using the boulder-oracle-sprint branch and your PYTHONPATH is pointing to that. Fabio Gomes wrote: > I tried it and i m getting this error: > > > File "/usr/lib/python2.4/site-packages/django/db/backends/firebird/base.py", > line 100, in quote_name > name = '"%s"' % util.truncate_name(name.upper(), get_max_name_length()) > AttributeError: 'module' object has no attribute 'truncate_name' > > Any ideas? > > On 12/18/06, Fabio Gomes <[EMAIL PROTECTED]> wrote: > > Thanx man, i ll test it right away. > > > > I was trying to hack your old one, but i didnt figure out why some > > generators weren´t created, so i was having some problems. > > > > -- Forwarded message -- > > From: David Elias <[EMAIL PROTECTED]> > > Date: Dec 18, 2006 1:14 PM > > Subject: New firebird backend using the boulder-oracle-sprint branch > > To: Django developers > > > > > > > > Please check http://code.djangoproject.com/ticket/1261 > > > > David Elias > > > > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: New firebird backend using the boulder-oracle-sprint branch
I was able to reproduce this error by enable the admin in the INSTALLED_APPS and in urls.py but not sync'ed to database, make sure you call manage.py syncdb to install also the admin app. Fabio Gomes escreveu: Thanx, it worked now. I was able to create the table, acess the objects, add, update and delete data.. but i get this error when i try to use the django admin: (-204, 'isc_dsql_prepare: \n Dynamic SQL Error\n SQL error code = -204\n Table unknown\n DJANGO_ADMIN_LOG\n At line 1, column 530.') --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: New firebird backend using the boulder-oracle-sprint branch
Is there anything i can help with? I m don´t have much python knowledge Same with me :) but i m really interested in firebird support in django, so if i can help testing or doing something it will be a pleasure. Well you can use this patch on your projects and report bugs and enhancements. also, is there any plans to add it in the main django release in the future? Well it all depends, for now, the oracle branch. I was also trying to build the Django ORM around SQLAlchemy sql package, not the ORM package, but that's another story. Again, thanx a lot for doing this great job :) Sempre às ordens! ^^ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Schema Evolution branch?
Hey all, I've been hacking on my application for a bit now, and I'm at the point where I'd want to be able to evolve my schema, rather than blow away the data or futz around with SQL to upgrade stuff. So I took a look at the schema-evolution branch, and it looks mostly abandoned. Is this the case? Is the code there still desired in general for Django? If so, and if nobody is actively working to get it running, how can I help to get this branch back on its feet and polished? - Dave --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: select_related() changes
http://dpaste.com/hold/4541/ :) On Jan 10, 8:39 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Updated paste:http://dpaste.com/hold/4539/ > > Should be no problems now :) > > On Jan 10, 8:22 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > > Code Source:http://dpaste.com/hold/4538/ > > > This replaces django/db/query.py and adds two arguments for > > select_related(): > > > depth=N, the recursion depth, by default, infinite, follows any key > > where blank isn't True > > fields=[], a list of fields, right now only supports fields from the > > base table. I'd like to extend this to be able to do > > relatedfield__fieldname, as well. if fields is not empty it will change > > depth to 1 > > > I think i've worked out all the kinks and if a few of you could give it > > a workout it'd be great. I'd like this to become core functionality as > > I feel its needed. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: select_related() changes
What's the svn command for generating the diff? On Jan 10, 11:07 am, Michael Radziej <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] schrieb: > > > Updated paste:http://dpaste.com/hold/4539/Thanks for your code, and I would > > have good use for some > improvements on select_related. But it's hard for me to see what > changed in the paste. > > The common way to suggest or discuss changes on this list is to > open a ticket with an attached diff and then start a discussion > refering to the ticket number. It's much easier to deal with > this, and the contributions don't get lost. Emails come and go, > tickets stay ;-) > > If you have problems creating a diff or so, let us know and > someone will surely assist. > > Cheers, > > Michael > > -- > noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - > Tel +49-911-9352-0 - Fax +49-911-9352-100 > > http://www.noris.de- The IT-Outsourcing Company --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: select_related() changes
Any links to an example ticket so I can keep a normal format for what im going to post? :) On Jan 10, 11:40 am, "Honza Král" <[EMAIL PROTECTED]> wrote: > On 1/10/07, David Cramer <[EMAIL PROTECTED]> wrote: > > > > > What's the svn command for generating the diff?svn diff > > you go into the top-level directory of your checked-out django, do svn > diff and capture the output > > > > > > > On Jan 10, 11:07 am, Michael Radziej <[EMAIL PROTECTED]> wrote: > > > [EMAIL PROTECTED] schrieb: > > > > > Updated paste:http://dpaste.com/hold/4539/Thanksfor your code, and I > > > > would have good use for some > > > improvements on select_related. But it's hard for me to see what > > > changed in the paste. > > > > The common way to suggest or discuss changes on this list is to > > > open a ticket with an attached diff and then start a discussion > > > refering to the ticket number. It's much easier to deal with > > > this, and the contributions don't get lost. Emails come and go, > > > tickets stay ;-) > > > > If you have problems creating a diff or so, let us know and > > > someone will surely assist. > > > > Cheers, > > > > Michael > > > > -- > > > noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - > > > Tel +49-911-9352-0 - Fax +49-911-9352-100 > > > >http://www.noris.de-The IT-Outsourcing Company-- > Honza Král > E-Mail: [EMAIL PROTECTED] > ICQ#: 107471613 > Phone: +420 606 678585 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: select_related() changes
http://code.djangoproject.com/ticket/3275 Thanks :) On Jan 10, 2:50 pm, Nikolaus Schlemm <[EMAIL PROTECTED]> wrote: > > Any links to an example ticket so I can keep a normal format for what > > im going to post? :)take a look at the tickets with patches: > >http://code.djangoproject.com/report/12 > -- > cheers, > > Nikl --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: select_related() changes
Not quite sure what to write in terms of the documentation :) On Jan 10, 4:07 pm, "Waylan Limberg" <[EMAIL PROTECTED]> wrote: > On 1/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > I'd like this to become core functionality as I feel its needed.For that > > to happen, you will likely need to do everything listed here > [1]. That includes writing some unit tests for the new functionality > and documentation explaining how to use it. In both cases they should > be submitted as diffs, just like the code. You can attach each as a > different file, or include everything all in one diff file. > > [1]:http://www.djangoproject.com/documentation/contributing/#patch-style > > -- > > Waylan Limberg > [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: select_related() changes
I can do the docs, but it'd be a great time saver if you could do the tests. I'm up to my elbows in work at the moment so :) On Jan 10, 4:37 pm, Michael Radziej <[EMAIL PROTECTED]> wrote: > Hi David, > > if you want me to write the docs or the tests, let me know. I > could deliver within a day or two. > > Michael > > -- > noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - > Tel +49-911-9352-0 - Fax +49-911-9352-100 > > http://www.noris.de- The IT-Outsourcing Company --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: select_related() changes
It seems there are some issues with the code. Although I'm not sure why it's happening, this was causing servers to get extremely loaded, and the SQL queries werent executing properly. I had no issues when running it on runserver before we pushed it onto a live environment though. Going to look into it some more tomorrow, if anyone has any ideas let me know. On Jan 10, 5:45 pm, Michael Radziej <[EMAIL PROTECTED]> wrote: > David Cramer schrieb: > > > I can do the docs, but it'd be a great time saver if you could do the > > tests. I'm up to my elbows in work at the moment so :)Fine for me, then I > > take the tests. > > Michael > > -- > noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - > Tel +49-911-9352-0 - Fax +49-911-9352-100 > > http://www.noris.de- The IT-Outsourcing Company --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: select_related() changes
I retract my statement, we had some other random server configuration error that just happened to appear at the same time as us putting this live :) On Jan 10, 8:34 pm, "David Cramer" <[EMAIL PROTECTED]> wrote: > It seems there are some issues with the code. Although I'm not sure why > it's happening, this was causing servers to get extremely loaded, and > the SQL queries werent executing properly. I had no issues when running > it on runserver before we pushed it onto a live environment though. > > Going to look into it some more tomorrow, if anyone has any ideas let > me know. > > On Jan 10, 5:45 pm, Michael Radziej <[EMAIL PROTECTED]> wrote: > > > David Cramer schrieb: > > > > I can do the docs, but it'd be a great time saver if you could do the > > > tests. I'm up to my elbows in work at the moment so :)Fine for me, then I > > > take the tests. > > > Michael > > > -- > > noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - > > Tel +49-911-9352-0 - Fax +49-911-9352-100 > > >http://www.noris.de-The IT-Outsourcing Company --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
