unicode.. reject?
hi, i was wondering if it would be better to simply reject unicode data in django models. at least until better unicode support (http://code.djangoproject.com/wiki/UnicodeInDjango) arrives... that would mean that django would raise an exception when you try to assign unicode text into a text-accepting field. (or at save() time). the reason? i've just spent some hours debugging a problem, and now i know that when using postgresql, "unsafe" characters like ['] are not quoted if the string is unicode. they are quoted when the string is a byte-string. this only happens with the postgresql backend. it works fine with the sqlite3 backend. further debugging showed, that psycopg is at fault, because it quotes byte-string params, but not unicode-string params. also, take an unicode string, like u"gábor" (my name :-). you can assign it into a charfield, and if you save the model using sqlite3, it's going to be ok. but if you do it with psycopg, you get a segmentation fault (on fedora), or a bus-error (on osx). this is again a problem with psycopg. of course, it's possible to simply in the django-code explicitly convert unicode strings to byte-strings. that would be the second approach. but please note, that if we follow the python-behaviour, then the auto-conversion should happen using us-ascii. which means we can only convert ascii-unicode-text, the rest will have to raise an exception. or perhaps use settings.DEFAULT_CHARSET? so because there are so many possible problems, i think requiring byte-strings would be the best approach. after all, even with the current situation, the ONLY safe way to use django is to explicitly convert every string into byte-string when putting it into a model. so, what do you think about such approach? p.s: of course it's quite possible that i simply overlooked a DO_WHAT_GABOR_NEEDS setting in settings.py, so if that's the case, please tell me :-) thanks, gabor --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
.delete() a little too eager?
I got curious about how Django deals with deletes in cases where an object refers to some other object as I noticed that this seemed to happen automagically in the admin interface. So I set up a silly little example: class Company(models.Model): name = models.CharField(maxlength=50) def __str__(self): return self.name class Admin: pass class Transaction(models.Model): buyer = models.ForeignKey(Company, related_name="buyers") seller = models.ForeignKey(Company, related_name="sellers") price = models.IntegerField() class Admin: pass class Subproject(models.Model): technology = models.CharField(maxlength=40) def __str__(self): return self.technology class Admin: pass class Reduction(models.Model): year = models.IntegerField(core=True) volume = models.IntegerField() subproject = models.ForeignKey(Subproject, edit_inline=models.TABULAR) When I delete a subproject, the contained reductions are all deleted. The admin interface also tells me about this fact, and it is the most sensible thing to do as reductions only exist as part of a subproject. However, when I set up two companies, and a transaction between them, I was expecting to see some sort of error message when I tried to delete one of the companies, as doing so manually causes Postgres to complain (rightfully): # delete from test_company where id = 1; ERROR: update or delete on "test_company" violates foreign key constraint "test_transaction_buyer_id_fkey" on "test_transaction" DETAIL: Key (id)=(1) is still referenced from table "test_transaction". So, I deleted the company in the GUI, and got a message saying that the delete operation would delete the company (no mention of the transaction the company was involved in). To my surprise, the delete went fine, and the company actually disappeared from the DB. Even worse, so did the transaction! I repeated the same thing in the shell, using the delete() function, same behaviour, the delete() call works fine, and both the company and the transaction disappears. In my opinion this must be a bug, as this causes data to be deleted when in fact it should not. Apparently Django figures out which transactions refer to the company in question, and deletes them all. I don't think this behavior should be the default. However, it might be useful in some cases, so being able to specify that it should happen might not be a bad idea. --~--~-~--~~~---~--~~ 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: introduction
Hi Chris, The implementation detailed on the wiki appears to give the granularity that several people around here (including myself) have been looking for, minus the various points that have already been brought up. An ACL-type solution as opposed to UNIX-style permissions certainly seems more flexible. My concern is that there's no details suggesting precisely how to implement one of the more common scenarios: when you want to specify that users can only have certain permissions for rows they've created themselves. An example of this would be your forum - apart from moderators, you only want users to be able to edit their own posts. Clearly, with the given proposal, it would be possible (and necessary) to create a new permission row for each data row the user generates. This is not especially hard, but a straightforward generic mechanism for doing this would be nice (which is to say, a mechanism that allows the admin system to generate the appropriate permissions when a user creates a new row). There might be one or two other similar situations the want considering, but this is my personal bugber at the moment. Anyway, looking good. -Andy PS: would Luke's GenericForeignKey allow for inline editing, assuming it was to be adopted? Personally I'd much rather be able to alter a row's permissions on its own admin page than have to switch table. --~--~-~--~~~---~--~~ 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: unicode.. reject?
On 5/28/06, gabor <[EMAIL PROTECTED]> wrote: > further debugging showed, that psycopg is at fault, because it quotes > byte-string params, but not unicode-string params. > > also, take an unicode string, like u"gábor" (my name :-). you can assign > it into a charfield, and if you save the model using sqlite3, it's going > to be ok. but if you do it with psycopg, you get a segmentation fault > (on fedora), or a bus-error (on osx). this is again a problem with psycopg. Comment from out of nowhere: how does psycopg2 hold itself in these cases? -- Jeroen Ruigrok van der Werven --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
EVOLUTION - Add Field Schema Evolution Support
After reviewing the relevant source code base a little, I have started with the implementation of the schema evolution skeleton (which will contain a functional "Add Field" support). http://case.lazaridis.com/multi/wiki/DjangoSchemaEvolution With a very small assistance from the team (mostly subjecting constructs and of course review of resulting code), I estimate to have a working solution within 3 days. My questions to the team is: Can I have a branch / or sandbox location for this (within the django SVN), or do I have to setup an own svn? If it is possible to create a branch, please assign me the username "lazaridis_com". Basicly I would prefere to place the code in an own SVN, but there are several organizational problems (synchronization etc.), which I have not solved yet. Additionally, the django core developers should have access to the code, thus they can directly apply the neccessary corrections / additions. . -- http://lazaridis.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
SoC 2006: Generic Authorization
I've posted an intial revised version of my summer of code proposal at: http://code.djangoproject.com/wiki/GenericAuthorization This should go hand in hand with Chris Long's RowLevelPermissions project: http://code.djangoproject.com/wiki/RowLevelPermissions Also, for the curious, you can see the other accepted proposals for Django at: http://code.google.com/soc/django/about.html Please post any comments to the list. I'm really excited... we're going to see some cool things in django-land in the next few months (not like there hasn't already been lots of cools stuff though ;) Thanks Joseph --~--~-~--~~~---~--~~ 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: A bug in reverse url lookup? (and a possible patch)
I created a ticket for this: http://code.djangoproject.com/ticket/2025 --~--~-~--~~~---~--~~ 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: Reversal Lookup TODO Needed
I created a ticket for this http://code.djangoproject.com/ticket/2025 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
NO 1 website for IT Jobs
Hello and Hi Today, I tell you another Best Website for finding the best job. Please check this link and enjoy your dream job. http://www.it-jse.com Special thing about this website is, they are presenting direct links to jobs. They are using only Direct Employers and not using Staffing Companies, Contract firms, Agencies, recruiters. I have checked this website Warm regards Bruce Smith --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
