Re: postgresql last_insert_id issue
There was already a discussion several times about that. It would be
definitely woth reviewing.
There's another ticket related to this with patches and tests (duplicate?)
http://code.djangoproject.com/ticket/13941
A.
--
Ales Zoulek
+420 604 332 515
Jabber: ales.zou...@gmail.com
--
On Thu, Jul 29, 2010 at 12:58 AM, Simon Meers wrote:
> The patch here [1] fixes this if anyone feels like reviewing. This bug is
> preventing me from using trunk on several projects at present, so it would
> be great to get the patch checked in. It also fixes a number of other
> problems people have been reporting, I believe.
>
> Simon
>
> [1] http://code.djangoproject.com/ticket/13821
>
>
> On 29 July 2010 03:19, ryan_peaceworks wrote:
>>
>> Hi,
>>
>> I'm running trunk and I found an issue where my model's tablename
>> contains uppercase characters.
>>
>> svn praise says this broke in r13363
>>
>> r13363 russellm # Use pg_get_serial_sequence to get the
>> underlying sequence name
>> r13363 russellm # from the table name and column name
>> (available since PostgreSQL 8)
>> r13363 russellm cursor.execute("SELECT
>> CURRVAL(pg_get_serial_sequence('%s','%s'))" % (table_name, pk_name))
>>
>> The issue is that table_name is not double-quoted when necessary.
>>
>> Probably the string argument should be self.quote_name(table_name)
>> rather than just table_name.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
--
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.
Filebrowser functionality in contrib?
I use django-filebrowser in a number of projects and find it invaluable. As of a while ago, Filebrowser became dependent on django- grappelli, which massively changes the default Django admin. Meanwhile, Grappelli has morphed and (I feel) become a pain in the neck to work with (buggy and difficult to configure). There is a forked project called django-filebrowser-no-grappelli which aims to bring the good old filebrowser behavior back to the non- grappelli Django back-end, but it's not clear whether that project is stable enough for production just yet. So I feel like my editorial team is stuck with a buggy Grappelli just because they need FileBrowser, and the way out of the mess is unclear. Not an ideal situation. I've been thinking that it seems like solid file management would be a good candidate for inclusion in contrib, but wanted to put feeler out on this list to see whether others might agree. Would this make a good 1.3 feature? -- 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.
Non-relational DataBases Support
I am a beginner. please keep that in mind when responding. Why Django is not yet integrated support non-relational databases? Django has the largest community among all Python frameworks. Other newer frameworks have integrated support for non-relational databases, such as web2py. Web2py is gaining much ground in developments on GAE. Know solutions such as Django-nonrel, I congratulate you for the initiative. But I would like to see a solution to this officially integrated with Django. I have read a little mailing list and see that there is disagreement in the solution. I wish they would come to an agreement, a final solution. Are you working on it?, If so, please refer me to help in any way possible, if not, say why are we so far behind that? I apologize for my English. -- 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: Non-relational DataBases Support
Vito, I am a beginner. please keep that in mind when responding. Why Django is not yet integrated support non-relational databases? Django has the largest community among all Python frameworks. Other newer frameworks have integrated support for non-relational databases, such as web2py. Web2py is gaining much ground in developments on GAE. Know solutions such as Django-nonrel, I congratulate you for the initiative. But I would like to see a solution to this officially integrated with Django. I have read a little mailing list and see that there is disagreement in the solution. I wish they would come to an agreement, a final solution. Are you working on it?, If so, please refer me to help in any way possible, if not, say why are we so far behind that? I apologize for my English. Have you looked at Neo4Django? http://journal.thobe.org/2009/12/seamless-neo4j-integration-in-django.html Hope that helps, James -- 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: Advanced Permissions
I'm certainly interested in it, although I'm not a Django core developer. Have you given any thought to allowing users to only read or update a subset of the fields of a given model? We have a very complex home-grown authorization system at the company I work for that I'm very interested in replacing with something more standard/mainstream. Also, with module-level permissions (which may be more like app-level permissions if I understand what you're proposing correctly), is there a possibility for one app to make use a permission defined in another? For instance, I may have one app (say, united_states_polling) with DemocratPoll and RepublicanPoll models as described in your description and another app (say, great_britain_polling) with ToryPoll and LabourPoll models. I would then possibly want to make use of a module-level permission defined for the united_states_polling app in the great_britain_polling app. Thanks for working on this problem. Peace, Andrew On Tue, Jul 13, 2010 at 12:08 PM, Nate wrote: > Hello. My name is Nate. Myself and my friend Marco would like to > upgrade django permissions. We would like to brainstorm here first to > make sure that we design something that fits with django. > > If there are any other discussions about upgrading django permissions, > kindly point me to them. We have already some of the permissions > threads on django-dev, but we thought that it would be best to make a > new thread for our proposal. > > We are aware of the fact that django 1.2 added some hooks for row- > level permissions, but this proposal covers an even broader scope. > > > # The Proposal # > > In a nutshell, we would like to add a PermissionManager to django. It > will be similar in concept to the 'objects' queryset Manager that > already exists on models. Each model will have a default > PermissionManager attached. People can override this PermissionManager > with their own PermissionManager to change the permissions for a > particular model. > > The default PermissionManager works like the current permissions > system: it checks all of the Backends to see if the user has the given > permission. (This, in turn, checks the records of auth.Permission by > default.) The simplest use case of the PermissionManager is overriding > it to add new permissions, equivalent to setting the Meta.permissions > attribute. For example: > > class Poll(models.Model): > permissions = PermissionManagerWith(vote='Can Vote') > ... > > Note that PermissionManagerWith would be a factory function to create > a new PermissionManager class with a vote permission. More on this > later. > > Unlike the current system, PermissionManagers make a distinction > between two types of permissions: object-level (row-level) and model- > level permissions. Model-level permissions are similar to the current > permissions that django has, while object-level permissions add more > fine-grained control. > > > ## Model Level Permissions ## > > Each PermissionManager has an 'allows_PERM' classmethod for each model- > level permission. For example, a PermissionManager with the model- > level permissions 'add', 'remove', and 'edit' will have the functions > 'allows_add', 'allows_remove', and 'allows_edit'. These functions take > a User object as a parameter and return a boolean as to whether or not > the user has the given permission. So, for instance, a user could do > the following: > > if not Poll.permissions.allows_vote(user): > raise PermissionError > > By default, this will check all of the authentication Backends to see > if the user has the given permission. Users could, of course, extend > PermissionManager and override this behavior to use other methods of > checking the permissions. > > Note, however, that these functions are defined on a Class level. > Users overriding these functions can not do any computation concerning > a model instance, only a model class. This does not allow people to do > things like restrict edits to only models that the editor created. For > that, you need object-level permissions. > > > ## Object Level Permissions ## > > Each PermissionManager has a 'PERM_list' classmethod for each object- > level permission. For example, a PermissionManager with the object- > level permissions of 'remove' and 'edit' will have the functions > 'remove_list' and 'edit_list'. These functions take a User object as a > parameter and returns a queryset of all the objects for which the user > has the specified permissions. So, for instance, you might see > something like this in contrib.admin: > > queryset = Book.permissions.edit_list(user) > > By default, this is either all of the objects or none of the objects, > depending upon the authentication backends. However, this is what is > overridden to get more fine-grained permission control. For example, > consider the following: > > class BookPermissionManager(PermissionManager): > def edit_list(self, user): > return super(BookPermissionManager, > self).ed
Re: Non-relational DataBases Support
Hi Vito -- On Thu, Jul 29, 2010 at 3:41 PM, Vito wrote: > Are you working on it?, If so, please refer me to help in any way > possible, if not, say why are we so far behind that? If you read over the archives on this list for the last couple-three months you'll see that there's a *lot* of activity in this space right now. Most of the activity is happening outside of core development; for example: * django-nonrel (which I see you've seen) * mango (Django/MongoDB integration): http://github.com/vpulim/mango * couchdbkit (not Django-specific, but integrates well): http://couchdbkit.org/ etc. In (or near) to the core, there's Alex Gaynor's Summer of Code project, which is hiding under the innocuous name "query-refactor" (http://code.djangoproject.com/svn/django/branches/soc2010/query-refactor/), but is focusing on laying the groundwork for NoSQL support. So I hope you can see it's being worked on -- just perhaps not in the way you might think. See, we're a fairly conservative project: we only include code once we know it's solving a very big need and once we know our solution is correct (we are, after all, perfectionists). I think the last couple of years have demonstrated that NoSQL does, in fact, fulfill a very real need, so now we're in the "make sure it's correct" phase. This by definition can't happen in the core; it needs space and freedom to evolve. Django will likely ship with first-class support for non-relational databases at some point in the future, but "at some point" is about as definitive as we can get. If you're impatient, do what I do: start using non-relational databases with Django *right now*! There are perfectly good Python binding libraries for every NoSQL DB out there, and integrating them with Django is usually a very easy thing. I have Django projects in production that use Redis, MongoDB, and CouchDB and all work fine and were pretty easy to write. 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.
The Web framework for perfectionists and innovative with deadlines.
On 29 jul, 17:39, Jacob Kaplan-Moss wrote: > Hi Vito -- > > Jacob Mr Jacob Kaplan-Moss, I am very happy to receive a response from you. It is a very valuable information. I just like to say something, to you and the rest of Django developers: Django is a framework made by perfectionists for perfectionists, but it is not good that they are as conservative. I guess it's not an easy job to have a framework so robust and yet so modern that supports the latest technology. I have to go a long way to keep up with the developers of Django, but soon I will be and try to help in the project from now. I think every time a new technology comes out you should start a conversation to begin to discuss how it will be integrated into Django, so that, sooner rather than later, Django supports the latest technology: not only database, also client side technologies, web 2.0, security. etc. In this highly competitive world can not be conservative. Django become: The Web framework for perfectionists and innovative with deadlines. -- 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: The Web framework for perfectionists and innovative with deadlines.
On Fri, Jul 30, 2010 at 7:16 AM, Vito wrote: > > > On 29 jul, 17:39, Jacob Kaplan-Moss wrote: >> Hi Vito -- >> >> Jacob > > > Mr Jacob Kaplan-Moss, I am very happy to receive a response from you. > It is a very valuable information. > > I just like to say something, to you and the rest of Django > developers: > > Django is a framework made by perfectionists for perfectionists, but > it is not good that they are as conservative. I guess it's not an easy > job to have a framework so robust and yet so modern that supports the > latest technology. > > I have to go a long way to keep up with the developers of Django, but > soon I will be and try to help in the project from now. > > I think every time a new technology comes out you should start a > conversation to begin to discuss how it will be integrated into > Django, so that, sooner rather than later, Django supports the latest > technology: not only database, also client side technologies, web 2.0, > security. etc. Hi Vito, Thanks for the suggestion. However, I would like to make a couple of comments in defence of our "conservative" approach. Firstly, the Django core team (and, for that matter, everyone else working on Django) is a volunteer group. We have limited time and resources, so we can't spend all our time discussing what might be or could be. If we did this, we would spend all our time discussing, and no time actually *doing*. The good news is that we don't need to have a single coordinated centralized discussion in order to make progress. Since Django is an open source project, anyone can contribute. If you think that an emerging technology is important, you have the source code, so you can try to implement an interface to that technology. If your change requires modifications to Django's core, you can propose those changes. Rather than have a start the process with a speculative "should we implement" or "how could we implement" discussion, we prefer to let the community establish what is possible, and let the community make a concrete proposal based on practical experience. For example, there has been lots of interest recently in NoSQL data stores. As a result, several groups have gone off and built NoSQL interfaces that can be used in Django. Some of these are unrelated to Django. Some of these leverage parts of Django, but work without any modifications to core. Some are effectively a speculative fork of Django. However, as a result of these independent projects, we're now in a position to be able to recommend a good path forward for the core -- and that's what Alex is implementing in the Summer of Code. Secondly, Django has a very strong policy of backwards compatibility. Once we introduce an API, we guarantee not to change it. That means we need to be *slightly* conservative when we adopt. We don't want to introduce an API for NoSQL in version 1.3, only to completely change the interface in version 1.4. We also don't want to end up having to support dozens of bad interfaces to emerging technologies that never really get beyond the initial buzz phase of their lifecycle. Thirdly, it's also important to note that just because a technology is important, it doesn't mean it needs to be part of Django. For example, you mentioned client-side technologies. Django is a server-side framework. Why does Django need to evolve client-side features? Why can't those feature emerge as a separate project? On the other end of the stack, Django doesn't need to evolve into a web server, either. We'd rather Django be a small project surrounded by a vibrant community of other small projects, rather than try and evolve Django into a massive "do-everything" framework. Lastly, its important to note that just because Django doesn't have a baked-in solution for doesn't mean it can't be done in a Django stack. As Jacob pointed out, there are already several ways to do NoSQL in a Django project. So -- if you think there is some emerging technology that Django should support, the first step is to try to implement your idea independent of Django itself. Try and work out if it can be a standalone project, or a library that 'plugs in' to existing Django interfaces. If it turns out that means changes are required in Django to support your new idea, feel free to make a suggestion, explaining why those changes are required. We're always open to suggestions -- but we're even more open to people in the community making the wider Django ecosystem a richer and more vibrant place to live. 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: Filebrowser functionality in contrib?
On Thu, Jul 29, 2010 at 3:32 PM, shacker wrote: > > I've been thinking that it seems like solid file management would be a > good candidate for inclusion in contrib, but wanted to put feeler out > on this list to see whether others might agree. Would this make a good > 1.3 feature? -1 For whatever it's worth, my sense is that there are a number of these types of third party apps out there, and no single one is a clear winner. Furthermore, I don't really see what adding file management to contrib gives us (it seems to work just fine as a third party app), and I'd hate to see innovation stifled at this stage by including one of the implementations in contrib. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 USA: +1 (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-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: Filebrowser functionality in contrib?
On Fri, Jul 30, 2010 at 11:09 AM, Tobias McNulty wrote: > On Thu, Jul 29, 2010 at 3:32 PM, shacker wrote: >> >> I've been thinking that it seems like solid file management would be a >> good candidate for inclusion in contrib, but wanted to put feeler out >> on this list to see whether others might agree. Would this make a good >> 1.3 feature? > > -1 > For whatever it's worth, my sense is that there are a number of these types > of third party apps out there, and no single one is a clear winner. > Furthermore, I don't really see what adding file management to contrib > gives us (it seems to work just fine as a third party app), and I'd hate to > see innovation stifled at this stage by including one of the implementations > in contrib. I completely agree with Tobias. The general description for a contrib app is a "defacto standard implementation of a common pattern". While Grapelli's filebrowser may be very useful functionality, I don't see it meeting these criteria. That said - I *would* be interested in any proposal to improve the interface that contrib.admin provides so would make it easier to plug in external features such as a file browser. If django-filebrowser has become dependent on Grapelli, I presume this was to leverage some benefit of Grapelli that Django's native admin wasn't providing. To me, this points at a deficiency in Django's admin that should be addressed. 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: memcached-based-cache - timeout=0 does not work as intended by memcached
On Tue, Jul 27, 2010 at 4:04 PM, SmileyChris wrote: > > I agree with Carl. > We have an abstracted api - having a property with different meanings > for different backends makes things a lot less pluggable. Sure. Upon closer investigation, I think this is pretty much a non-issue. My only point is that all cache backends should receive whatever timeout they're passed, unmolested by Django. Given that all the backends, besides memcache, are implemented in the Django source, I see no reason why they couldn't be modified on a case by case basis to support a "cache forever" option, indicated by timeout=0, while leaving the common code intact and without really co-opting anything. Establishing this as a loose convention seems like a reasonable enough plan to me. I will say that the memcache issue seems more like a bug, while special-casing timeout=0 for all the other backends seems more like a feature (and one that may require a lot more discussion, code, and testing relative to the 1-line memcache fix). Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 USA: +1 (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-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: Filebrowser functionality in contrib?
On Jul 29, 8:09 pm, Tobias McNulty wrote: > > For whatever it's worth, my sense is that there are a number of these types > of third party apps out there, and no single one is a clear winner. I would have to respectfully disagree - FileBrowser is far and away the clear winner. There are no viable alternatives that I can find (if someone can point one out, I'm all ears). > Furthermore, I don't really see what adding file management to contrib > gives us (it seems to work just fine as a third party app), ... except that it's not working just fine (because of this dependency on Grappelli). > and I'd hate to > see innovation stifled at this stage by including one of the implementations > in contrib. I definitely agree in principle about not stifling innovation. But at the same time, one of the important jobs of a framework is to handle tasks that are common to many web sites. I'd say that file management falls into that category. But I certainly won't press on this if the developers disagree. On Jul 29, 8:28 pm, Russell Keith-Magee wrote: > That said - I *would* be interested in any proposal to improve the > interface that contrib.admin provides so would make it easier to plug > in external features such as a file browser. If django-filebrowser has > become dependent on Grapelli, I presume this was to leverage some > benefit of Grapelli that Django's native admin wasn't providing. To > me, this points at a deficiency in Django's admin that should be > addressed. The author stated the reason in a ticket once but I'm having trouble finding it. It was along the lines of what you're saying here. I'll post something and see if I can get details on exactly what he was trying to overcome. Thanks for the feedback. Scot -- 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 #14007: Automatically discover models within a package without using the app_label Meta attribute
Hi, The process of model discovery is not modified by this patch. Continue reading for more details. - Mark polymorphic is an interesting case, as it only defines one model and that model is abstract. Therefore polymorphic doesn't need to be in INSTALLED_APPS (and perhaps my example is therefore dumb). The way Django currently works (in django.db.models.base.ModelBase) is that the app_label for a model is determined by "looking one level" up from the module the model is *defined* in. This has the interesting effect that models are discovered by the mere fact of importing them; they don't need to be defined in a module named models. Currently when PolymorphicModel is imported from polymorphic (either by writing "from polymorphic import PolymorphicModel" or "from polymorphic.polymorphic_model import PolymorphicModel"; the class is available in both modules), the app_label is determined to be "polymorphic" since "polymorphic" is one level up from "polymorphic_model" in "polymorphic.polymorphic_model", which is the module PolymorphicModel is actually defined in. My patch mimics this behavior. As another example, consider a model defined in myapp.tests (this is done in the tests provided with the patch). Models in myapp.tests are discovered since myapp.tests is imported when running tests. app_label is determined to be "myapp" in this case since "myapp" is one level up from tests in "myapp.tests". Now consider a model defined in myapp.models.some_models. app_label would currently be determined to be "models" since "models" is one level up from "some_models" in "myapp.models.some_models". This is not the desired behavior, so a Meta class must be defined with the attribute app_label = "myapp" to rectify the situation. My patch makes is so that Django looks one level up from the last occurrence of "models", if present. app_label then doesn't need to be explicitly specified for every model when factoring a app's models module into sub modules. What's strange about all this is that if you currently (and with my patch) define a model in myapp.package.other_models and other_models gets imported, then SomeModel in other_models will have the bogus app_label "package" since "package" is one level up from "other_models" in "myapp.package.other_models". This turns out to be harmless most of the time since sql isn't generated for apps that aren't in INSTALLED_APPS (although you're in trouble if you actually try to use a model with a bogus app_label). The one freaky case is when you actually have an app named "package", in which case sql will be generated for the bogus models as well as the expected models. This strangeness is present is Django currently, and my patch doesn't fix of modify this behavior. - Mark On Wed, Jul 28, 2010 at 9:46 AM, burc...@gmail.com wrote: > Hi Mark, > > > For 'polymorphic.polymorphic_model' it would be 'polymorphic'. > Is that correct this didn't work at all (or didn't work properly) > before your patch, and now works properly, so one can put > "polymorphic.polymorphic_model" into their INSTALLED_APPS and > everything would work? > Should one import polymorphic_model from polymorphic.__init__ and put > "polymorphic" into INSTALLED_APPS? > Should one import polymorphic_model from polymorphic.models and put > "polymorphic" into INSTALLED_APPS? > > In few words, how does the models discovery work for this case with your > patch? > > -- > Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, > MSN: bu...@live.com > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- 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.
