Oracle backend TextField unique=True error
Hi all, I've run into a situation where syncdb produces an error on one of my models against Oracle, but not against Postgres. Using Postgres, one can mark a TextField as unique=True, and syncdb works just fine. Using Oracle, you get an error: > cx_Oracle.DatabaseError: ORA-02329: column of datatype LOB cannot be > unique or a > primary key The error is occurring for someone using some code of mine (django-ldap-groups), rather than something I'm seeing directly. I don't currently have access to an Oracle instance to test against. FWIW, I remember running into this sort of limitation back when I used Oracle a few years ago, any LOB field was basically opaque -- no indexing, no uniqueness, etc. Is this limitation known? Is this an error on my part, that I shouldn't be trying to mark a TextField as unique? Or should this be something that should be specially handled by the Oracle backend somewhere? If the latter, I'm happy to file a bug report. Thanks very much for all your hard work in creating and improving Django, I really appreciate all your work, it's made my life much easier. Regards, ---Peter Herndon -- 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: Oracle backend TextField unique=True error
On Dec 18, 2009, at 12:02 PM, Ian Kelly wrote: > On Fri, Dec 18, 2009 at 9:00 AM, Peter Herndon wrote: >> Hi all, >> >> I've run into a situation where syncdb produces an error on one of my models >> against Oracle, but not against Postgres. Using Postgres, one can mark a >> TextField as unique=True, and syncdb works just fine. Using Oracle, you get >> an error: >> >>> cx_Oracle.DatabaseError: ORA-02329: column of datatype LOB cannot be >>> unique or a >>> primary key >> >> The error is occurring for someone using some code of mine >> (django-ldap-groups), rather than something I'm seeing directly. I don't >> currently have access to an Oracle instance to test against. FWIW, I >> remember running into this sort of limitation back when I used Oracle a few >> years ago, any LOB field was basically opaque -- no indexing, no uniqueness, >> etc. >> >> Is this limitation known? Is this an error on my part, that I shouldn't be >> trying to mark a TextField as unique? Or should this be something that >> should be specially handled by the Oracle backend somewhere? If the latter, >> I'm happy to file a bug report. > > This is known. The Oracle notes [1] mention that TextFields cannot be > indexed. Since Oracle requires indexes for unique columns, this also > means they cannot be unique, although we should probably make that > explicit. It may also be worthwhile to check for this when the models > are validated. > > Ian > > [1] http://docs.djangoproject.com/en/1.1/ref/databases/#textfield-limitations > Thanks much, Ian. Hmm. Speaking from the perspective of a user of a reusable third-party app, what I'd most like to have happen is, when I run syncdb, the model validation checks for this, notices it is a TextField and removes any index or unique, and prints a line telling me that it has done so. That way, the syncdb has done as much as it can while inconveniencing me the least, yet still letting me know. On the other hand, there's something to be said for just popping a more descriptive error message and stopping. Wait for the user explicitly to choose how to repair the impossible-to-fulfill request to index the TextField, rather than guess at how to proceed. But then there's the difference in database implementation. That is, marking a TextField unique in Postgres is valid. How should I, as a reusable app author, handle this issue? Should I be checking for database type in my model code, and adjust the field definition accordingly? Should I just document the hell out of it and move on? Or remove the unique, and default to the lowest common denominator? Thoughts? Thanks again, ---Peter -- 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: Oracle backend TextField unique=True error
On Dec 22, 2009, at 12:04 AM, Mario Briggs wrote: > Hi Ian, > > Ian Kelly wrote: >> Not currently, no. And if I were to put in some work on improving on >> the Oracle backend's support for filtering on TextFields, I would >> concentrate first on fixing the query so that it correctly compares >> the entire TextField and not just the first 4000 characters. >> Unfortunately, I don't think any function-based index will help with >> that. > > hmmm. I am thinking differently. I think most of these use-cases where > someone is doing a value based look up on a 'Text' would be a > situation similar to what Russ has in admin view - the type is not > fixed, it is could be any one of the types. However it is definetly > not 'length unlimited' and the modeler has a fair idea of what the > broad upper limit would be. > > I think if it is really length-unlimited, then automatically there > shouldnt be a use-case to do a value based lookup or have a unique > index for it (unless it is once in a blue-moon, anything really > frequent and performance will not be usable). Definetly there could > be a valid need for a google-style search of the column and this is > where DB2 and Oracle support 'Text' indexing of LOB columns. > > Peter, maybe you can elaborate why you choose 'Text' and why you need > an a unique index on it. > I chose TextField in order to store long LDAP DN strings. At my place of work, our LDAP has quite a bit of depth in the tree, and OU and CN names can be quite long, which result in some very long strings to store. I could conceivably use a CharField with an extremely large max_length, say 1024 or 2048, but with TextField I don't need to worry about overrunning the max length. The LDAPGroup model itself is a mapping between an LDAP OU group membership, and a django.contrib.auth.models.Group, used to associate a given Django group and the permissions assigned to it with any LDAP-authenticating user who belongs to the OU. When an LDAP user logs in, their LDAP group memberships are checked. If one of those groups is mapped to a Django group, then their Django user model is automatically assigned to the mapped Django group, thereby giving the user whatever access rights are assigned to the group. I marked the TextField unique in order to ensure that there is one and only one mapping instance per LDAP OU. The LDAPGroup mapping instance can map a single LDAP OU to multiple Django Groups, but I wanted to make sure there was only one such mapping in order to avoid having to search through multiple mapping instances to find all the places where an OU might be used. In this case, there's only one mapping per OU. The system would work if I used CharField, but I might run into cases where the OU is longer than the max_length on the CharField. The system would also work if I relaxed the unique constraint on the OU, but then the database table would have redundancies. I realize I'm somewhat abusing the notion of a TextField at the database level. In this case, I want to treat it like an unlimited length varchar. Or, the mirror perspective, I want to be able to guarantee uniqueness of a CLOB. I hadn't thought much about the limitations in Oracle's treatment of CLOBs, since I'm using Postgres myself, where this works. ---Peter -- 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
On Jan 21, 2010, at 9:58 AM, Luke Plant wrote: > On Tuesday 19 January 2010 21:26:17 Jacob Kaplan-Moss wrote: > >> 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. > > Thanks for your clarification elsewhere in this thread. > > One question I have (for Jacob and anyone else with experience): > > I would have guessed that a big issue with Django from an enterprise > perspective is its use of 'singletons'. Though we don't use that > terminology, we have dozens of them in the code - every other setting > we have implies the existence of a singleton, since the setting can > have only one value. For example, EMAIL_BACKEND means that we have > one email component singleton which is used everywhere. If you wanted > one set of views to use a different email backend, you are out of > luck. > > The 'admin' app was the first major component to allow multiple > instances, but there are various other apps which might need this > change in theory. > > How much is this an issue in practice? Speaking as a web developer using Django in a *very* enterprisey corporation, I will say this singleton issue has been a problem for me. As a self-inflicted example, I wrote an LDAP backend that looks up the necessary settings from settings.py. I need to rewrite it to store the settings in the db, because I need to be able to query multiple LDAP sources. I run into similar issues with lots of different apps. So yes, singletons are an issue for me. The difference between ops settings vs. app settings has also been a problem. The lack of established, vetted best practices (for deployment, layout, everything Russ mentioned) also has bitten me regularly. In part because I wind up spending a lot of time doing the research to figure out what I need to do, in part because the state of the art moves forward at a rapid pace. But, to put it in perspective, I'm the only person who even *can* deploy a Django app at my place of work. Which is not great, but I'm also a Linux sys-admin, so it is at least in my job description. But none of my fellow SAs have any clue what to do to get stuff working on one of our corporate RHEL 5 boxen, and no inclination to learn. Anyway, I'm glad to see this discussion taking place. Django indeed has a sweet spot, and it isn't really for enterprise installations -- though it is *very* good in that sweet spot. There are places where the early design decisions to favor convention over configuration impose a lack of flexibility in favor of simplicity. A definite trade-off. It makes it harder to use in places where flexibility and integration are required. Here's a big question, though: given that satisfying the enterprise crowd, of which I am an occasional part, will require additional "stuff" that may bring along with it additional complexity, making it potentially harder to get started for newbies, is that a direction that the project should head? Is it worth satisfying the enterprise crowd to increase adoption, at the cost of turning into the kind of configuration hell that J2EE servers exemplify? Or, more positively, is it possible to add the required enterprisey bits while still maintaining a certain level of simplicity? Note that Django is already headed towards greater complexity (multi-db, email backends), due to requirements from the current community. My two cents, appropriately adjusted for the current economic situation. ---Peter Herndon -- 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 documentation for newer users
On Mar 5, 2010, at 11:35 AM, stherrien wrote: > What I'm suggesting is that we setup something to allow everyone to > improve the docs with help from the core django group. I think this > would be very helpful to everyone. if one of the core group would like > to help us get setup to do this it would be great. maybe if they setup > a repository with the current online docs online so we can add updates > as we do with django itself. There are a couple of relevant pages on how to work with the documentation: http://docs.djangoproject.com/en/1.1/internals/contributing/#documentation-style http://docs.djangoproject.com/en/1.1/internals/documentation/#internals-documentation Feel free to check out the project, make changes, file bug reports, and submit patches. Documentation quality is taken pretty darned seriously, from what I've seen. -- 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.
No default comment_notification_email.txt, no docs
Hi all, I just ran into a minor issue and thought I'd bring it to light. In adding django.contrib.comments to a site I'm building, I found that when using moderation and setting email_notification to True, that there is no default template for comment_notification_email.txt included with the other comments templates. There is also no documentation I could find that mentions what context is provided to the template. I found it easily enough by reading the email method of the CommentModerator class in django/contrib/comments/moderation.py, but that seems less than optimal. I'm happy to open a ticket, but should the solution be to include a default template, to add relevant documentation pointing out the customization possibility, or both? Regards (and many thanks for an incredible framework!), ---Peter Herndon -- 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: No default comment_notification_email.txt, no docs
On Nov 8, 2010, at 9:14 AM, Carl Meyer wrote: > Hi Peter, > > On Nov 7, 9:41 pm, Peter Herndon wrote: >> I just ran into a minor issue and thought I'd bring it to light. In adding >> django.contrib.comments to a site I'm building, I found that when using >> moderation and setting email_notification to True, that there is no default >> template for comment_notification_email.txt included with the other comments >> templates. There is also no documentation I could find that mentions what >> context is provided to the template. I found it easily enough by reading >> the email method of the CommentModerator class in >> django/contrib/comments/moderation.py, but that seems less than optimal. >> >> I'm happy to open a ticket, but should the solution be to include a default >> template, to add relevant documentation pointing out the customization >> possibility, or both? > > In general, contrib.comments includes defaults for all the templates > it needs, which suggests this one ought to be included too. On the > other hand, contrib.auth doesn't include default templates for the > email it sends for password-reset. Hmm. My inclination is to say that > a simple default template for that email should be included, and the > docs should include mention of the template and the context it > receives. > > Carl > Hi Carl, I filed ticket 14646, with a patch including a default template and some additional documentation. ---Peter -- 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: [GSOC-Testing] Kubasik Status Update
Yes! Even if I don't make it to Djangocon, I'd still love to see the info available. ---Peter Herndon http://spookypony.com On Jul 12, 2009, at 3:34 AM, Kevin Kubasik wrote: > So I was traveling some this week and getting back into the swing of > things back here in Utah. I didn't get to the twill backend I wanted > to write this week, but I did start to write real documentation. > > The other thing I wanted to measure responses on is submitting a > talk on windmill integration at djangocon. Would there be interest? > > -- > Kevin Kubasik > http://kubasik.net/blog > > > --~--~-~--~~~---~--~~ 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: Feature request: admin notifications
On 07/29/2009 05:05 AM, Daniel Pope wrote: > My suggestion is a system for administrators to be notified about > specific model instances about which they need to take action. At > present administrators have to identify where to make changes by > browsing the site. Some example use cases: > > 1. Comments - a list of new comments requiring moderation. > 2. Stock level low - a list of SKUs with fewer than say, 5 items left in > stock. > 3. Draft articles - a list of unpublished articles, for the > convenience of administrators. > 4. Data inconsistencies - while model validation should do for any > really functional inconsistencies, I often come across situations > where I want to warn admins rather than outright forbid the model to > be saved. Case in point: I want to warn if the number of products in a > category would require me to paginate them onto 2 pages as this is > undesirable for usability. > > I would propose a way to register notification querysets in the admin. > If a non-zero number of results present, a message appears in the > admin, including the number of items to administer, and a link to a > changelist that displays only matching models. I'd ideally like to > select an icon too, so that I can differentiate between alerts, > warnings and mere information. > > Dan > Hi Dan, One fairly simple way to do this would be to set up a Notification model to hold these kinds of notifications, build a nice admin.py and some admin templates for it, and then build post_save signal handlers for each (Stock, Comments, etc.) that create new Notifications when appropriate. You can add in email, SMS, and/or Twitter alerts in the signal handlers in order to get push notifications. This seems like a straight-forward approach, but it isn't particularly generic. You'd need to code custom logic for each of your post_save signal handlers -- if any new comment is posted, then notify; if stock is reduced and total amount of stock is < 5, then notify; if # of products in a category > 10, then notify. Hmm. One could code up a base signal handler, and a library of signal handler subclasses that handle configurable logic variations. Similarly, one could create a base notify action, and a library of notification subclasses to implement various features. And perhaps some means of chaining them -- base Notify creates a Notification, then do an Email notification, then do a Twitter notification. I'd say, though, such a framework should start life as a third-party reusable app. Neat idea, this would be something I would likely use. ---Peter --~--~-~--~~~---~--~~ 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: Supported Python versions for Django 1.7
Hi all, For those on RHEL6 or a derivative, please note that RHEL Software Collections will provide an installation source for Python 2.7 and 3.3, as well as Postgres 9.2 and both MySQL 5.5 and MariaDB 5.5, and works for RHELs 6.2-6.4. Furthermore, "With the notable exception of Node.js, all Red Hat Software Collections components are fully supported under Red Hat Enterprise Linux Subscription Level Agreements, are functionally complete, and are intended for production use." https://access.redhat.com/site/documentation/en-US/Red_Hat_Software_Collections/1-Beta/html/1.0_Release_Notes/chap-RHSCL.html I ran across this announcement via Nick Coghlan. So, there's a supported version of Python 2.7 and 3.3 for RHEL 6, which should make Python deprecation choices easier. I would suggest that the above link get some mention in the documentation, as this will make things much easier to sell in shops that value stability and support, if this alternative solution is better known. Regards, ---Peter On Jun 29, 2013, at 5:08 AM, Florian Apolloner wrote: > Hi, > > On Friday, June 28, 2013 4:17:22 PM UTC+2, Aymeric Augustin wrote: > As far as I can tell, there's a consensus on dropping support for Python 2.6. > That will allow us to remove the vendored copy of unittest2 and to take > advantage of datastructures introduced in Python 2.7 like OrderedDict. > > Oh yes, getting rid of our vendored unittest2 is totally worth it (debugging > failures when someone imports from below django.utils.unittest2 is no fun)! > > Cheers, > Florian > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: Porting Django to Python 3.0 as a GSoC project
As Alberto said, and James and Jacob, I don't see enough value for Django. The key here is to define a project that results in a usable code contribution by the end of the summer *for the project*. Not for Python3k, but for Django. If you want to port Django to Python3k for Python 3.0's benefit, where Django is simply an example code base, well, submit that to the Python folks. In addition, one of the side benefits is to get another contributor of code to the project, right? Is the student in question willing to commit to working on a project that doesn't finish over the summer? It's much easier to maintain a finished project of reasonable scope than it is to continue working on a project of larger size once the initial time commitment and incentive have lapsed. I'm not arguing against porting Django, I think it's a good idea. And I like the sound of "Django3k". :) I would encourage the student to commit to that project, just not under the aegis of SoC. Do it because it is useful, but do it on the side. Do something else for SoC, of a more reasonable scope and immediate payoff. Regards, ---Peter --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
