Re: django/db/models/sql/where.py: line 215
I'm afraid that I can't help you with the specific problem that you are describing, but I would like to recommend that you look at the work that Waldemar Kornewald and Thomas Wanschik are doing with their django-dbindexer: http://www.allbuttonspressed.com/blog/django/joins-for-nosql-databases-via-django-dbindexer-first-steps Their project may be solving the same basic problem you are trying to solve, but in a more generalized way, and in a way that supports more recent versions of Django. Although their primary objective is to simulate relational functionality in non-relational systems, I'm sure they would be open to seeing how their tool can make multi-db easier for relational databases. -- 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: Intermittent IOError exception raised and emailed to admins during file upload.
Well, if this is a problem with WSGI, why not enhance the specification in the way Graham proposed? I'm sure that whoever is responsible for writing the spec is open for suggestions like this one (while WSGI attempts to be as lean as possible, I'd say that not being able to reliably know when a connection to the server broke client-side is a major shortcoming). And while that is an ugly, ugly idea, this could be implemented in common wsgi implementations now. Thomas On Fri, Feb 4, 2011 at 4:23 PM, Jacob Kaplan-Moss wrote: > On Fri, Feb 4, 2011 at 2:45 AM, Tai Lee wrote: >> It seems to happen with very small file uploads as well. I've seen it >> reported with 30KB uploads, while at the same time 60MB uploads work. If I >> can't find a problem with the server causing disconnects, and it is actually >> on the client side, I'll just have to continue to ignore the exception >> reports Django emails as a result :) > > Based on my experience with this error (which, sadly, is extensive) > it's almost certainly client-side. When there are server-side > disconnects it's not intermittent: every server-side disconnect issue > I've seen has been reproducible and thus fixable. > > But there's a whole bunch of client-side issues that could be causing > this, and you probably can't do anything about it. Some examples of > where the problem can be: > > * Browser: you can get this when a user just clicks the "stop" button > or navigates away. Some browsers close the connection cleanly; others > don't. > * Browser: some versions of IE, especially on Vista, randomly > terminate uploads. Most of the time it's seemed to be related to the > windows firewall thing. > * Browser: various development versions of Firefox, Chrome, and Safari > have all had upload/disconnect issues. To my knowledge none of these > issues have made it into shipping versions, but many users of these > browsers use the cutting edge. > * Dodgy 'net connections, especially public ones. For example, I can > pretty consistently trigger an IOError by uploading a file from Kansas > City International Airport. > * Badly-configured intermediary caches, like those run by ISPs. AOL > dialup users (yes, there are still some of these!) seem to throw lots > of IOErrors. (I traced this town by noting that certain /24 and /32 IP > spaces seemed more prevalent in the error tracebacks and tracked down > those block owners.) > > So yeah, all of those are out of your control, which is why I (and > many others) usually just say to ignore the error. > > However, I think it's a bad idea to automatically suppress these > errors (which you could do with a piece of middleware or a custom log > handler in 1.3). That's because this error could *also* be caused by > something misconfigured on your end (a messed up HTTP load balancer, > for example). So if you just suppress the error you could end up > missing something that *is* fixable. > > So we're back to "read and then ignore," sadly. I would *love* a > better way, but I can't think of one. > > 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 > 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-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: Question on ForeignKey (on_delete=DO_NOTHING)
I have ran the test suit in debugging mode also, and what i observed is sqlflush worked perfectly. I am currently investigating into this, if found something, will update you same. Thanks, Rahul Priyadarshi On Feb 4, 10:54 pm, Carl Meyer wrote: > On Feb 4, 3:41 am, Rahul wrote: > > > When i set this flag in DatabaseFeatures then for full test suit also > > both test cases of "contenttypes" app works fine. > > > But i am not able to figure out why this test case was failing when we > > were not sets supports_transaction flag. > > It may be worth investigating this, because the most likely cause is a > problem with your implementation of sqlflush for your backend. This > could be a problem for other uses of "flush", even if switching the > tests away from flush makes the symptom disappear in this case. > > Carl -- 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: Abstract ManyToManyField
2011/2/5 Carl Meyer > > Hi Mike, > > On Feb 3, 4:36 pm, Mike Lindsey wrote: > > I'm doing something with bidirectional ManyToManyFields, in a project > > I'm working on, that is resulting in duplicate attempts to create the > > intermediate tables. I'm perfectly open to suggestions of "You're > > doing it wrong" if they come with advice on how to fix my problem, > > without losing the easy Admin insertion of the relationships (without > > resorting to InLines, which don't seem to play nicely at all with > > FieldSets). Right now I'm getting around the problem by running > > syncdb, running dbshell to drop the table it complains about, and > > rerunning syncdb; repeating until syncdb finishes successfully. > > > > What would make this exceptionally easy, is if there was the option to > > set 'abstract=True' on second iteration of each of the > > ManyToManyFields, telling syncdb to not attempt to create it. > > So what you're trying to do here is simply not supported. I'm guessing > you've already concluded as much. This means that, for now, there is > no good answer for you (that I'm aware of). Whatever hack or > workaround you are able to come up with is what you're gonna get. > Sorry. BTW the ticket for this is #897 [1] and there is a suggested workaround (explicit declaration of the 'through' table) which isn't *too* ugly and might help you in the short-term? Simon [1] http://code.djangoproject.com/ticket/897 -- 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: Intermittent IOError exception raised and emailed to admins during file upload.
As a datapoint, I've had 9 of these errors from 5 different people (2 people retried 3 times each) and 30 successful uploads from 14 different people in the past 7 days on a low traffic site (300 visits). That's a pretty low success rate. Seven of the errors had a user agent indicating MSIE 8, one was MSIE 7, and one was Chrome on OS X. If almost 25% of upload attempts are failing, and 33% of users are experiencing difficulty, that seems to indicate that web browsers (especially MSIE) are extremely unreliable at performing uploads. I'd love to see some data on the reliability of uploads on other higher traffic sites across different browsers and using different server side technologies, to see if this really is typical. Cheers. Tai. On Feb 5, 2:23 am, Jacob Kaplan-Moss wrote: > On Fri, Feb 4, 2011 at 2:45 AM, Tai Lee wrote: > > It seems to happen with very small file uploads as well. I've seen it > > reported with 30KB uploads, while at the same time 60MB uploads work. If I > > can't find a problem with the server causing disconnects, and it is > > actually on the client side, I'll just have to continue to ignore the > > exception reports Django emails as a result :) > > Based on my experience with this error (which, sadly, is extensive) > it's almost certainly client-side. When there are server-side > disconnects it's not intermittent: every server-side disconnect issue > I've seen has been reproducible and thus fixable. > > But there's a whole bunch of client-side issues that could be causing > this, and you probably can't do anything about it. Some examples of > where the problem can be: > > * Browser: you can get this when a user just clicks the "stop" button > or navigates away. Some browsers close the connection cleanly; others > don't. > * Browser: some versions of IE, especially on Vista, randomly > terminate uploads. Most of the time it's seemed to be related to the > windows firewall thing. > * Browser: various development versions of Firefox, Chrome, and Safari > have all had upload/disconnect issues. To my knowledge none of these > issues have made it into shipping versions, but many users of these > browsers use the cutting edge. > * Dodgy 'net connections, especially public ones. For example, I can > pretty consistently trigger an IOError by uploading a file from Kansas > City International Airport. > * Badly-configured intermediary caches, like those run by ISPs. AOL > dialup users (yes, there are still some of these!) seem to throw lots > of IOErrors. (I traced this town by noting that certain /24 and /32 IP > spaces seemed more prevalent in the error tracebacks and tracked down > those block owners.) > > So yeah, all of those are out of your control, which is why I (and > many others) usually just say to ignore the error. > > However, I think it's a bad idea to automatically suppress these > errors (which you could do with a piece of middleware or a custom log > handler in 1.3). That's because this error could *also* be caused by > something misconfigured on your end (a messed up HTTP load balancer, > for example). So if you just suppress the error you could end up > missing something that *is* fixable. > > So we're back to "read and then ignore," sadly. I would *love* a > better way, but I can't think of one. > > 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Hello Django developers
Hi, My name is Juan Antonio (aka ersame) from Spain and I am a computer science student . I have been enrolled in some Django projects since September 2010. I think it’s time to start contributing in this amazing project. I just want to say hello to everybody and if someone could make a review of my first ticket (http://code.djangoproject.com/ticket/15175) I would be very grateful, because I do not know if I am doing it well. By the way, congratulations to the Spanish (Castilian) translation team we almost finish. Thank you all and regards, Juan A. Infantes. -- 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/db/models/sql/where.py: line 215
On Thu, Feb 3, 2011 at 6:40 AM, Sneaky Wombat wrote: > I'm not sure what sort of answer this question will lead to, but here > goes. I know foreignkeys on separate databases isn't supposed to work, > according to the django docs, but I got it to work. First off, I'm > using an old release (1, 2, 0, 'alpha', 1), one of the earlier multidb > releases. Because I hacked on it for so long and so much to make it > work for my needs, I've literally ended up with a branch of my own to > maintain. As such, I port features in as I need them from various > patches to the trunk. It sucks, but anyway, I came across a problem > where I wanted to use django-pyodbc to connect to a mssql server on > another machine. This machine was not my default router, in fact, it > was the third database I moved into my dbrouter. Further complicating > my design, (lack thereof) I needed to use a field on a table in this > mssql database as a foreign key to my primary database (mysql). > > I don't want to be lectured on my use of foreign keys like this, I > know. > > At first it seemed ok, and then I found a nugget on the django doc > pages that said foreign keys to external databases are not allowed/ > won't work. (http://docs.djangoproject.com/en/dev/topics/db/multi-db/ > #cross-database-relations) Since I ported/added things I needed in the > past, I didn't let this deter me. I pressed on. After a lot of > experimenting, I discovered a very strange behavior. Take this for > example: > > class mssqlTable(Model): > # this is one of three non-default databases in my db router > # this would get selected explictly using db_for_read/write > display = models.CharField(max_length=128) > def __unicode__(self): > return "mssqlTable:%s"%self.id > > class mysqlTable(Model): > # this is in my default database in my db router > assignee = models.ForeignKey(mssqlTable) > display = models.CharField(max_length=128) > def __unicode__(self): > return "mysqlTable:%s"%self.id > > Now the weirdness, and I think Model.objects.defer has it's hands in > this somewhere, but didn't look too hard there, other than watch it > try to defer in pdb. > > launch the shell: python manage.py shell > import the models... > x=mysqlTable.objects.all() > > As long as I don't try to do: > > x.assignee > > It works great. As soon as i try to hit that deferred field though, > it pukes with a horrible error that comes up from django-pyodbc. I can > see x.assignee_id though, that is populated with an int value of the > FK from the external DB. However, if I do: > > x=mysqlTable.objects.all()[0] > > x.assignee > > it works great! I never did find out exactly what that slice does, > but I later surmised that the slice is causing the connection.alias to > hold the right handle to the right database. Then you surmised very, very badly. It does a little more than that. mysqlTable.objects.all() is a queryset. It's a representation of a group of objects resulting from a query. By taking the slice, you are pulling out a single object from that query. Hence, x = mysqlTable.objects.all() x.assignee doesn't work, because a list of objects doesn't have an assignee. x = mysqlTable.objects.all()[0] x.assignee does work, because the first object in the result set has an assignee. This has nothing to do with multi-db -- it's a fundamental part of how querysets work. Without wanting to be rude -- if you haven't got a grasp of this level of detail of Django, you might want to consider whether you're up to the task of making cross-database joins work. However, if you're still confident you can get the job done, there are two issues that you'll need to resolve: 1) The mechanics in Foreign keys that prohibit cross-database joins. There isn't currently any way to remove these checks, so you'l need to do some customization. I'm not fundamentally opposed to making these checks 2) The process of retrieving remote objects when you use foreign key accessors. This should really just be a matter of using to_python() to turn a foreign key value into a remote query. I'm not sure why "where" comes into this whole discussion, because cross database queries aren't *ever* going to work (or, at least, they aren't going to work without some *serious* effort). An implementation of cross-database foreign keys shouldn't need to do anything with the WHERE clause AFAICT. Defer doesn't have anything to do with it either. Foreign Keys don't use the same mechanics as deferred fields. A deferred field is the idea of "don't retrieve column X until it is explicitly requested". Foreign Keys always retrieve the *primary key* of the related object, but lazily load the related object when it is requested. Similar idea, but quite different implementation. However, you're in pretty much unexplored territory here. Conceptually, it should be possible, but there are reasons why we dropped cross-database joins from the multi-db implementation that we delivered :-)
Re: Hello Django developers
On Mon, Feb 7, 2011 at 6:24 AM, Juan Antonio Infantes wrote: > Hi, > > My name is Juan Antonio (aka ersame) from Spain and I am a computer science > student . I have been enrolled in some Django projects since September 2010. > > I think it’s time to start contributing in this amazing project. I just want > to say hello to everybody and if someone could make a review of my first > ticket (http://code.djangoproject.com/ticket/15175) I would be very > grateful, because I do not know if I am doing it well. Your patch addresses the problem in a reasonable way, there's a test to validate the edge case in question. There's no docs required because it's just a bug. That's all we need, so I've just marked the ticket Ready For Checkin. 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.
Re: Admin DateTimeShortcuts performance (feature request / improvement suggestion)
Fabian, On Jan 28, 11:18 am, Fabian Büchler wrote: > [...] > As an addition, I think it would make sense to integrate the jQuery UI > datepicker (maybe with a timepicker extension [1]) instead of the existing > one, because that might resolve some problems, as with the datepicker > opening outside of the viewport when the calendar icon is too far on the > right side of the screen. > While your jQuery UI dependency inclusion proposal is discussed I'd like to focus in the specific datepicker calendar outside of viewport problem you describe. We fixed a related problem regarding negative vertical positions in [1]r15143 closing ticket #11414. You seem to be proficient in JavaScript and hopefully have a way to reproduce the issue so if you can identify the exact problem maybe we can fix it in the short term. Please feel free to open a ticket with your findings, bonus points for a patch fixing it :) Thanks for taking the time to help us with all those issues and enhancements. Regards, -- Ramiro 1. http://code.djangoproject.com/changeset/15143 2. http://code.djangoproject.com/ticket/11414 -- 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: Hello Django developers
On Mon, Feb 7, 2011 at 11:40, Russell Keith-Magee wrote: > On Mon, Feb 7, 2011 at 6:24 AM, Juan Antonio Infantes > wrote: >> Hi, >> >> My name is Juan Antonio (aka ersame) from Spain and I am a computer science >> student . I have been enrolled in some Django projects since September 2010. >> > Your patch addresses the problem in a reasonable way, there's a test > to validate the edge case in question. There's no docs required > because it's just a bug. That's all we need, so I've just marked the > ticket Ready For Checkin. Juan, Congrats! L. -- Crunchiness is the gustatory sensation of muffled grinding of a foodstuff. Crunchiness differs from crispiness in that a crispy item is quickly atomized, while a crunchy one offers sustained, granular resistance to jaw action. While crispiness is difficult to maintain, crunchiness is difficult to overcome. from The Best of Wikipedia http://bestofwikipedia.tumblr.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.
