RequiredIfOtherFieldsGiven validator
I noticed (after inferring it probably exists) the RequiredIfOtherFieldsGiven validator, though it is currently undocumented. The default error message is, "Please enter both fields or leave them both empty." The actual test is: def __call__(self, field_data, all_data): for field in self.other: if all_data.get(field, False) and not field_data: raise ValidationError, self.error_message Since field_data is a constant, this is equvalent to: def __call__(self, field_data, all_data): if field_data: return for field in self.other: if all_data.get(field, False): raise ValidationError, self.error_message i.e. if this field is set, then if any of the other fields are not set, it's invalid. So the error message is wrong or there's a bug. Based on the name of the validator, I think the problem is in the error message. It should be more like "Please either enter this field or leave the other ones empty." What I actually need for my app is OnlyIfOtherFieldsGiven, which in fact is what the RequiredIfOtherFieldsGiven validation error claims to be doing. The test for OnlyIfOtherFieldsGiven would be: def __call__(self, field_data, all_data): for field in self.other: if bool(all_data.get(field, False)) ^ bool(field_data): raise ValidationError, self.error_message (Yes, bitwise-exclusive-or actually will work on booleans.) If there's some interest in actually having this in Django, let me know and I'll write up a ticket with patch. -- This message has been scanned for memes and dangerous content by MindScanner, and is believed to be unclean. --~--~-~--~~~---~--~~ 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: Extra options for DatabaseWrapper
On 11/1/06, Yasushi Masuda <[EMAIL PROTECTED]> wrote: > > As in the ticket #2866, I think it would be nice if DatabaseWrapper has > extra keyword options, which are passed to individual DB-API connection > object constructor. +1 I had been thinking about putting a patch together for the MySQL backend so that things like read_default_file and read_default_group and sql_mode could be used, but I think there is no practical reason not to make this a option for all backends. -- This message has been scanned for memes and dangerous content by MindScanner, and is believed to be unclean. --~--~-~--~~~---~--~~ 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: why error: (10054, 'Connection reset by peer') when add user?
On 12/22/06, yichao.zhang <[EMAIL PROTECTED]> wrote:
my env:
python 2.4.3, django-0.95-py2.4, WinXP sp2
I created a new project, enabled the admin feature.
After logging into admin as superuser, I press the button "Add user",
then the following error occurs. It's reproduciable against mysql and
sqlite3.
I don't see how *this* error can be reproducible against sqlite3...
Exception happened during processing of request from ('127.0.0.1',
1276)
Traceback (most recent call last):
File "D:\Python243\lib\SocketServer.py", line 222, in handle_request
self.process_request(request, client_address)
File "D:\Python243\lib\SocketServer.py", line 241, in process_request
self.finish_request(request, client_address)
File "D:\Python243\lib\SocketServer.py", line 254, in finish_request
self.RequestHandlerClass(request, client_address, self)
File
"D:\Python243\lib\site-packages\django-0.95-py2.4.egg\django\core\servers
\basehttp.py", line 537, in __init__
BaseHTTPRequestHandler.__init__(self, *args, **kwargs)
File "D:\Python243\lib\SocketServer.py", line 521, in __init__
self.handle()
File
"D:\Python243\lib\site-packages\django-0.95-py2.4.egg\django\core\servers
\basehttp.py", line 581, in handle
self.raw_requestline = self.rfile.readline()
File "D:\Python243\lib\socket.py", line 340, in readline
data = self._sock.recv(self._rbufsize)
error: (10054, 'Connection reset by peer')
What versions of MySQL (client and server) and MySQL-python are you
using? The server is disconnecting abnormally.
--
Patriotism means to stand by the country. It does
not mean to stand by the president. -- T. Roosevelt
This message has been scanned for memes and
dangerous content by MindScanner, and is
believed to be unclean.
--~--~-~--~~~---~--~~
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: Constraints and MySQL
On Feb 27, 6:38 pm, "Ramiro Morales" <[EMAIL PROTECTED]> wrote: > On 2/27/07, Geert Vanderkelen <[EMAIL PROTECTED]> wrote: > > > > > Because the other Databases have 'limitations' or 'features' or > > 'defects' that MySQL might not have or whatever. Django is, as I have > > been told, database independent. And Django is working fine with > > MySQL, lets keep it that way. > > As Russell has said: > > > Reverting [4610] only serves to break Postgres; it > > won't return MySQL to working status. MySQL has never allowed forward > > references. We just didn't have a test that revealed the problem. > > Also, as Daniel pointed, MySQL is not following the SQL standard in > this specific issue. And considering Oracle now owns InnoDB I wouldn´t > hold my breath waiting for this being implemented anytime soon. InnoDB is not dead, and it's not the only game in town for transactional backends for MySQL: http://dev.mysql.com/doc/refman/5.1/en/storage-engines-other.html http://dev.mysql.com/doc/falcon/en/index.html Also, MySQL with MyISAM does pass the unit test for the same reason sqlite does: No foreign keys. Not that I'm advising anyone to use MyISAM in general. --~--~-~--~~~---~--~~ 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: Constraints and MySQL
Here's another possible solution/workaround: MySQL supports an IGNORE keyword on INSERT statements, which causes errors to be treated as warnings. http://dev.mysql.com/doc/refman/5.0/en/insert.html Not sure how hard it would be to incorporate this for this particular case, though. -- Patriotism means to stand by the country. It does not mean to stand by the president. -- T. Roosevelt This message has been scanned for memes and dangerous content by MindScanner, and is believed to be unclean. --~--~-~--~~~---~--~~ 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: Constraints and MySQL
On 3/1/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > > Andy Dustman: > > Here's another possible solution/workaround: MySQL supports an IGNORE > > keyword on INSERT statements, which causes errors to be treated as > > warnings. > > > > http://dev.mysql.com/doc/refman/5.0/en/insert.html > > > > Not sure how hard it would be to incorporate this for this particular > > case, though. > > You're sure? The docs say: > > "Specify IGNORE to ignore rows that would cause duplicate-key violations." > > The rows are ignored, not the errors. > > > I haven't tried it out, though. Neither have I, but the passage quoted above refers to a specific case with duplicate key errors. The problem here is not duplicate keys but missing foreign keys, and so I'm hoping what it will do is insert the row anyway and produce a warning. That is my interpretation of: "If you use the IGNORE keyword, errors that occur while executing the INSERT statement are treated as warnings instead." However, this needs to be tested, and even so, I'm not sure how hard this is to do within the context of the code. -- Patriotism means to stand by the country. It does not mean to stand by the president. -- T. Roosevelt This message has been scanned for memes and dangerous content by MindScanner, and is believed to be unclean. --~--~-~--~~~---~--~~ 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: Enforcing MySQLdb version(?)
Also, MySQLdb-1.2.1 is the first version which has support for MySQL-4.1, and MySQlL-4.1 is the first version with good character set support (in prior versions the client could not change the character set) and sub-selects. MySQLdb-1.2.1_p2 has an important bugfix, but it only matters if you are using MySQL-4.0 or older. MySQL-4.1.7 was the first production release for 4.1 back in October 2004, and support for 4.1 and 4.0 is limited (you can still buy it, apparently). MySQL-5.0.15 was the first production release for 5.0 back in October 2005. MySQL-5.1 is still beta but will likely be production in the next couple months. I would expect most people who are developing produciton websites with Django (and MySQL) to use Python-2.4 or 2.5 and MySQL-5.0 or possibly 4.1 or 5.1, depending on what they already have deployed. I personally am using Python-2.4 and MySQL-5.0 and the Django trunk. There may be some creaky old web hosting setups that still have 4.0 or possibly older. Even SourceForge, which is not exactly cutting edge, is using 4.1. That said, I think if you take the version test out, there's a pretty good chance that the current patch will work with MySQL-python-1.2.0 and MySQL-4.0 or older. --~--~-~--~~~---~--~~ 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: Enforcing MySQLdb version(?)
On 3/9/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Also, the link in http://code.djangoproject.com/ticket/3279#comment:14 > seems to indicate there are some real problems with 1.2.0. If there weren't problems, there wouldn't be a 1.2.1. :) > Or is that > not consistent with your understanding (I know you have quite a history > of MySQL + python work)? It's fair to say I have *all* the history: I've been the developer of MySQLdb since 1999 (maybe longer). -- Patriotism means to stand by the country. It does not mean to stand by the president. -- T. Roosevelt This message has been scanned for memes and dangerous content by MindScanner, and is believed to be unclean. --~--~-~--~~~---~--~~ 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: magic-removal: plans/estimates for the trunk-merge?
On 3/28/06, pbx <[EMAIL PROTECTED]> wrote: > > At this point I'm just pretending magic-removal *is* the trunk. I've > ported all my play stuff to it, am using the admin to manage content > for a couple existing non-Django sites, and am developing a production > site in it at work now as well. Most of the time the limiting factor in > functionality is my own competence, not bugs in the framework! I've only been working with magic-removal as well. It might be worth considering puting in some backwards-compatibility with 0.91, though, keeping a meta module but giving a deprecation warning if it's used, warning if your model has a META class, etc. I'm thinking meta can be a light wrapper around model in a lot of cases. It would probably help the early adapters a lot. The list of things that need to be changed when going from 0.91 to 0.92 is pretty large. And then remove the deprecated stuff prior to 0.93 or 1.0. One thing the Zope people are doing right is gradually integrating Zope 3 components into Zope 2 so that there's an easier migration path. Zope 3 is probably more like Django or Turbogears than Zope 2, though so far I think Django's a lot easier to learn than Zope 3. -- The Pythonic Principle: Python works the way it does because if it didn't, it wouldn't be Python. --~--~-~--~~~---~--~~ 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: needs testing: inspectdb for mysql5
On 3/30/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > > Hi, > > I've created a patch that allows inspectdb on mysql databases to > recognize the foreign keys; I'd like someone using mysql 5 to test this > patch if possible (I have only mysql 4 here, and I don't plan to use > version 5 ... but I'm willing to support this patch also for mysql 5) > > Would just be great. > > See http://code.djangoproject.com/ticket/1483 It reads OK, but your patch doesn't apply. It's kind of mangled up; look at line 17. -- The Pythonic Principle: Python works the way it does because if it didn't, it wouldn't be Python. --~--~-~--~~~---~--~~ 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: magic-removal: plans/estimates for the trunk-merge?
On 3/28/06, Max Battcher <[EMAIL PROTECTED]> wrote: > > Andy Dustman wrote: > > It might be worth considering puting in some backwards-compatibility > > with 0.91, though, keeping a meta module but giving a deprecation > > warning if it's used, warning if your model has a META class, etc. I'm > > thinking meta can be a light wrapper around model in a lot of cases. > > It would probably help the early adapters a lot. The list of things > > that need to be changed when going from 0.91 to 0.92 is pretty large. > > And then remove the deprecated stuff prior to 0.93 or 1.0. > > The whole point of M-R is that it is backwards-incompatible. Well, I know. > There are > a lot of exceptions thrown that should reasonably guide people through > the upgrade, and the final version of the RemovingTheMagic wiki page > should also be extremely handy. The problem is, while there are a lot of exceptions, you aren't going to get them all at once. You hit one, fix it, hit another, fix it, repeat ad nauseum. If you could generate deprecation warnings and still have things mostly work, that would probably making porting easier. I'm not suggesting expending a lot of effort to make everything backwards compatible, but some of it would appear to be not so hard, particularly emulating meta, since the module itself doesn't exist any more: Make a new meta that's a wrapper around models. I don't have a vested interest in 0.91 compatibility myself, because I've only ever really been using magic-removal. Maybe the compatibility helper could be an add-on/overlay of some sort and not in the standard distribution. > If 0.91 was 1.0, yes there should be a softer upgrade. However, 0.91 is > still 0.91. My only suggestion is that to point to the hard upgrade the > magic-removal merger, even though it should still be the next release, > should be 0.95 rather than 0.92 to make a larger contrast. I agree with this and I wonder if there are a sufficent number of bugfixes in the trunk to merit a 0.92 release that is just a bugfix release for 0.91. -- The Pythonic Principle: Python works the way it does because if it didn't, it wouldn't be Python. --~--~-~--~~~---~--~~ 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: needs testing: inspectdb for mysql5
On 3/31/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > Line 17 reads: > @@ -12,8 +18,58 @@ def get_table_description(cursor, table_ > > Can anyone tell me what I'm actually doing wrong? I don't know, but those are two lines mashed together somehow. How are you generating that diff? -- The Pythonic Principle: Python works the way it does because if it didn't, it wouldn't be Python. --~--~-~--~~~---~--~~ 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: Mixin Use Cases
On 3/31/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > Could anyone who want's mixins post some specific use cases > (preferably simple code samples) Basically, are people wanting > multiple inheritace for models, or do you just want a mixin to provide > some additional methods? I'm reasearching model inheritance a bit > more, and realized that I have no idea what people are looking for > when they say "I want mixins". Here's a use case for something that I'm actually working on: An administrative tool for djbdns's tinydns. Record format details are here: http://cr.yp.to/djbdns/tinydns-data.html General idea is to have one class/table for each record type. Note that all the records have some common elements: domain, ttl, timestamp (which I'm doing as starts and expires timestamps), and location. Additionally I would add some per-record metadata: added and updated. Also there would be some common methods. At present (in magic-removal), If I make a BaseRecord type with all the common attributes and then make other records subclass it (not exactly what you are asking for with mixins), I can create new entries fine, but I can't access them through the admin interface because it tries to pull them out of the wrong table (the superclass table). I also tried having the common elements as a mixin, but that didn't work right either. (I may have to revisit this, though.) I have some notes on the ModelInheritance page about possibly using views to simplify reading, and while none of the databases I could find could do a multi-table update through a view without writing stored procecures and triggers, I realized that individually updating the underlying tables is no worse than if you didn't use views. So views seem to be a win for reading and neutral for writing. -- The Pythonic Principle: Python works the way it does because if it didn't, it wouldn't be Python. --~--~-~--~~~---~--~~ 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: Mixin Use Cases
On 3/31/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > On 3/31/06, Andy Dustman <[EMAIL PROTECTED]> wrote: > > I have some notes on the ModelInheritance page about possibly using > > views to simplify reading, and while none of the databases I could > > find could do a multi-table update through a view without writing > > stored procecures and triggers, I realized that individually updating > > the underlying tables is no worse than if you didn't use views. So > > views seem to be a win for reading and neutral for writing. > > I thought the same thing, but I was both pessimistic and lazy. I > didn't beleive that the 3 main players (postgres, mysql, sqlite) would > all let you update and insert on views, and I didn't reasearch it to > make sure :) I'm not sure if this was clear, but at least MySQL-5.0, MS-SQL, DB2, and Oracle appear to allow you to update views that are based on joins, provided you only update underlying one table at a time. To update multiple tables, you need to use triggers (rules in the case of PostgreSQL, and I'm not sure views are updatable in PostgreSQL at all without writing a rule for each view) and stored procedures. However, the alternatives are updating the underlying tables with individual queries, or updating them using the view, but then you have to make sure you aren't touching more than one table at a time. I.e. if your class is spread across three tables, you'd have to make up to three queries when making an update, depending on what attributes/columns changed. The simpler alternative is close to what it does now: A subclass gets it's own tables, and inherits fields from the parent class. Right now it inherits the fields, but it seems like it also inherits the table name as well for select. And they don't inherit ManyToMany relations yet, but should. -- The Pythonic Principle: Python works the way it does because if it didn't, it wouldn't be Python. --~--~-~--~~~---~--~~ 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: helper functions
On 3/31/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > On Mar 31, 2006, at 1:30 PM, Alan Bailey wrote: > > IsModified() > > This could be useful, but it's probably not worth doing since Django > would have to keep two copies of all your data in memory to figure > this out. Doubling the memory footprint of Django isn't on my wish- > list :) Some time ago (about 3 yrs now and a bit at the 2005 PyCon)) when I was working on an ORM (SQLORB), the way I handled this was to keep a __uncommitted dict. There was a __setattr__ hook (and later properties) so that when you changed an attribute, it would be stored in __uncommitted, and also the object would be registered with the transaction manager (i.e. appended to a list). Then when you called commit() on the transaction manager, it would iterate over the list, and issue UPDATE for each object's __uncommitted data and then finally call commit() on the database connection. When doing getattr, it would check __uncommitted first, and then fall back to using the original property (if any) or __dict__. In that scenario, isModified() reduces to bool(obj.__uncommited). -- The Pythonic Principle: Python works the way it does because if it didn't, it wouldn't be Python. --~--~-~--~~~---~--~~ 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: DatabaseFeatures and supports_transactions
On Tue, Sep 25, 2012 at 7:57 PM, Russell Keith-Magee
wrote:
> On Tue, Sep 25, 2012 at 11:24 PM, maxi wrote:
>> No, I just answer because it caught my attention. Why not just trust in a
>> True/False property ?
>
> As I recall, the reason we can't just use a property is MySQL. There's
> no reliable way to tell whether the database has been set up as
> InnoDB, which supports transactions, or MyISAM, which doesn't. An
> experimental approach allows us to be certain.
Actually, there are several database engines in MySQL that support
transactions, not just InnoDB, though that's the most popular.
>> BTW, What do you mean with "commit/rollback/etc are simply no-ops" ?
>
> Exactly that. On databases that don't support transactions,
> commit/rollback etc are no-ops.
Not exactly. MySQLdb starts in transactional mode (required by
PEP-249), but if for some reason it's switched to autocommit mode,
rollback throws an exception. There's probably nothing in Django that
would set the connection to autocommit mode, though.
Additionally, MySQL (at least as of 5.0) will throw a warning ("Some
non-transactional changed tables couldn't be rolled back") if you do
try rollback on non-transactional tables If you run your MySQL session
in ANSI mode, this becomes an error and will produce an exception in
MySQLdb.
http://dev.mysql.com/doc/refman/5.0/en/ansi-diff-transactions.html
I've kicked around the idea of making a mysql_ansi database driver for
Django but there hasn't been a compelling reason to do it.
--
Question the answers
--
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: Removal of DictCursor from raw query.. why??
You can do something like:
for row in cursor:
dictrow = dict( (d[0], c) for d, c in zip(cursor.description, row) )
(izip may be better than zip. Your call.)
Or for the whole result set:
result = [ dict( (d[0],c) for d, c in zip(cursor.description, row) )
for row in cursor ]
On Thu, Jun 16, 2011 at 10:03 AM, Cal Leeming [Simplicity Media Ltd]
wrote:
> Okay, let me put it another way.
> Are there any plans to give developers an easy way to retrieve values from a
> cursor.fetchall(), in a DictCursor style?
> Default: ((Decimal('0'), Decimal('52'), Decimal('4159'), 9998L),)
> What I'm looking for:
> [{
> 'f1' : Decimal('0'),
> 'f2' : Decimal('52'),
> 'f3' : Decimal('4159'),
> 'f4' : 9998L
> }]
> Maybe something like cursor.fetchall(field_names=True), or
> cursor.dictfetchall() - which is what the removed function did.
> Cal
> On Thu, Jun 16, 2011 at 2:54 PM, Luke Plant wrote:
>>
>> On 16/06/11 14:10, Cal Leeming [Simplicity Media Ltd] wrote:
>> > Okay, er.
>> >
>> > In reference to the original problem (cursor's not default to
>> > DictCursor), thus no field names are returned, is there a specific
>> > reason for this? If not, I'll probably raise a ticket to have it
>> > considered for change.
>>
>> I'm not sure exactly what you are asking, because this is about default
>> behaviour. The choice of a default is usually made according to what is
>> thought to be the most useful, or according to the way it happens to
>> have been done in the past.
>>
>> I also don't know what exactly you are suggesting. Our backwards
>> compatibility policy means that we aren't going to change the default,
>> unless other people's code is going to work transparently (which
>> wouldn't be the case here), so it doesn't really matter what the
>> original reason was, if there was one. If you are suggesting that we add
>> some functionality to make use of DictCursor more useful, then certainly
>> the suggestion is valid.
>>
>> Regards,
>>
>> Luke
>>
>> --
>> The probability of someone watching you is proportional to the
>> stupidity of your action.
>>
>> Luke Plant || http://lukeplant.me.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.
>>
>
> --
> 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.
>
--
Question the answers
--
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: Should test failures/errors in the Django test suite when executed under MySQL be considered blockers?
And if is a real problem in the MySQL support, I'm willing to look into it. I use it in production. You might have to poke me directly but I am trying to pay attention lately. On Thu, Jun 23, 2011 at 5:53 PM, Jacob Kaplan-Moss wrote: > Hi Jim -- > > Historically, most Django core developers have been PostgreSQL users > (and advocates to some degree). This has meant that, yes, MySQL > support has lagged behind. It's not that MySQL support isn't > considered important, but it is a matter of priorities. I, at least, > am going to prioritize the database that I actually *use*. > > That said, I'm embarrassed by how bad the state of things is (though I > can't reproduce your need-to-modify-the-tests-even-to-get-them-to-run > thing), and we should certainly be doing better. It'll take someone > with the motivation to plink away at the MySQL issues, and I would be > thrilled if that's you. > > And yes, if the test suite isn't even *running* that should be > considered a release blocker! > > 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. > > -- Question the answers -- 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: Thoughts on solution to forward references in MySQL (#3615)
On Mon, Jun 27, 2011 at 6:08 PM, Jacob Kaplan-Moss wrote: > On Mon, Jun 27, 2011 at 4:24 PM, Jim D. wrote: >> I spent some time last week and over the weekend nailing down a >> solution for https://code.djangoproject.com/ticket/3615 . This is the >> ticket about allowing forward references when loading data on the >> MySQL InnoDB backend. My patch implements the proposed change >> (disabling foreign key checks when the data is loaded) as well as a >> straightforward SQL SELECT check for integrity after the data is >> loaded, which if I understand it is the missing piece that has >> prevented this ticket from moving forward for the last 4 years... > > Interesting approach -- I wouldn't have thought of this! It feels a > bit nasty to me, but it's rather close to how deferred constraints > work behind the scenes anyway. I'd like to see some feedback from > other people who're experienced with MySQL; I don't know enough about > any potential downsides to spot 'em. But I think you've found a way to > cut the knot of this problem, and barring a better solution I'd like > to check this one in. Disabling foreign key checks is exactly what mysqldump puts at the start of the dump. Presumably your database will have no bad references to start with, so the resulting dump shouldn't have any either, and thus be safe to load with foreign key checks off. http://dev.mysql.com/doc/refman/5.5/en/innodb-foreign-key-constraints.html (for reference) -- Question the answers -- 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: Timezone-aware storage of DateTime
On Thu, Jun 30, 2011 at 4:51 AM, Daniel Swarbrick wrote: > The main difference between MySQL's "timestamp" field type and > PostgreSQL's "timestamp with time zone" field type (and indeed also > MySQL's "datetime" field type) is the date range that they support. > MySQL's "timestamp" field type is modeled on Unix epoch timestamps, > and therefore does not support dates earlier than 1 Jan, 1970 00:00:00 > UTC. PostgreSQL's "timestamp with time zone" field type on the other > hand is modeled on Julian dates, and supports dates ranging from 4713 > BC to 294276 AD (with 1 µs accuracy, I might add). And MySQL's > "datetime" field type supports some bizarre range of > '-00-00' (yes, you really can specify the zero'th day of the > zero'th month... isn't that cool?) to '-12-31'. One can only hope > that Oracle's acquisition of MySQL might one day lead to better SQL > compliance. Uh, no. -00-00 is specifically an illegal value in MySQL. Invalid dates are converted to -00-00 unless you are in strict mode, in which case they raise error conditions. The actual supported range is from 1000-01-01 to -12-31. http://dev.mysql.com/doc/refman/5.0/en/datetime.html -- Question the answers -- 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: Timezone-aware storage of DateTime
On Thu, Jun 30, 2011 at 12:24 PM, Daniel Swarbrick wrote: > On Jun 30, 5:12 pm, Andy Dustman wrote: > >> Uh, no. -00-00 is specifically an illegal value in MySQL. Invalid >> dates are converted to -00-00 unless you are in strict mode, in >> which case they raise error conditions. The actual supported range is >> from 1000-01-01 to >> -12-31.http://dev.mysql.com/doc/refman/5.0/en/datetime.html > > I stand corrected. I stopped used MySQL for anything important back > around version 3.something, after it ate my data once too often. Since 4.0 came out in the late 1990s, isn't is possible that things have improved somewhat over your dozen year gap of ignorance? (I'll stop feeding trolls now) -- Question the answers -- 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: Thoughts on solution to forward references in MySQL (#3615)
If you aren't using InnoDB, then it probably doesn't matter if you turn foreign key checks on or off: it becomes a no-op. There are some other storage engines that support transactions, and some of them might "do the right thing" with respect to deferred foreign key checks, but I think it does no harm to disable the checks on loading fixtures on these engines. In other words, always turn them off when loading fixtures (and back on afterwards) and don't care about the storage engine and it should be fine. Keep it simple. On Jul 6, 2011 7:34 PM, "Russell Keith-Magee" wrote: > > On Thu, Jul 7, 2011 at 5:05 AM, Jim D. wrote: > > Are any core devs interested in taking a closer look at the current patch on > > this ticket (https://code.djangoproject.com/ticket/3615)? It's been through > > several rounds of revision after discussion here and on the ticket comment > > thread. > > Interested - most certainly. The issue (as always) is finding the time :-) > > I'm certainly grateful for your efforts; this is a long standing issue > that I'd love to see addressed; I'm just not in a position to commit > to anything. I'll put this on my list of things to look at, but I'm > not getting a whole lot of time to look at that list at the moment. > > > * There's a DB feature can_defer_constraint_checks . I couldn't find much > > by way of documentation or or usage of this feature. But I was trying to > > figure out if the work we are doing here is what this feature refers to, and > > if so, if we should be marking this as True for MySQL and SQLite with this > > implementation. I'm not sure there is other behavior that is required or > > expected in that attribute. Anyhow, that might also be a path forward for > > the issue I raise above (ie. we could skip the test if > > can_defer_constraint_checks is not True). > > This feature flag exists essentially to verify whether MySQL InnoDB is > currently in use. It isn't used during normal runtime; it's purely a > test skipping flag. It's used to identify tests that need to be > skipped because the test data requires a circular reference which > (historically) hasn't been possible under InnoDB because constraints > aren't checked. > > Essentially, this feature flag shouldn't need to exist at all; it only > exists so that InnoDB passes the test suite without errors. If we are > able to resolve the issue that allows MySQL to use forward references > in data, then this feature flag shouldn't be required at all. > > 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-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.
