I think it's also worth noting that MyISAM doesn't support foreign keys, which would make the object relationships that Django creates impossible.
-- Joey "JoeLinux" Espinosa Software Developer http://about.me/joelinux On Dec 16, 2011 8:40 AM, "Sells, Fred" <fred.se...@adventistcare.org> wrote: > Thanks for such a clear and helpful response. I’ll begin the upgrade > migration immediately. I noticed that a newer project does use InnoDB, yet > I don’t see anything in settings.py which specifies the engine in either > project. It’s been a while but the original project was built with Dj 1.2 > and I think it used XP while the newer one was built with 1.3 under Windows > 7.**** > > ** ** > > I wrote a little conversion script which seems to work and I notice that > MySQL 5.5 defaults to InnoDB. Here’s the trivial script if anyone can use > it.**** > > ** ** > > import MySQLdb**** > > Connection = MySQLdb.connect (db=*"mydb"*)**** > > Cursor = Connection.cursor()**** > > Cursor.execute(*'show tables'*) *#test connection***** > > tables = Cursor.fetchall()**** > > for table in tables:**** > > t = table[0]**** > > if t in *'vlog allfields editlog user'*.split(): continue #these are > views**** > > print t,**** > > sql = *'ALTER TABLE %s ENGINE=INNODB'* % t**** > > print Cursor.execute(sql)**** > > ** ** > > ** ** > > *From:* django-users@googlegroups.com [mailto: > django-users@googlegroups.com] *On Behalf Of *Ian Clelland > *Sent:* Thursday, December 15, 2011 1:02 PM > *To:* django-users@googlegroups.com > *Subject:* Re: Django 1.2.1 strange problem**** > > ** ** > > ** ** > > On Thu, Dec 15, 2011 at 5:56 AM, Sells, Fred <fred.se...@adventistcare.org> > wrote:**** > > I’ve got an older app that’s been running in production for about 2 years > on RedHat 4, MySQL 5.0.77 with MyISAM tables, Django 1.2.1 and Python 2.4. > **** > > **** > > This app is used heavily by internal users, which is a relatively light > load compared to public sites. I actually use Flex for the client side and > save each field when the user changes it.**** > > **** > > About once a month one field in particular will have its value cleared, or > perhaps the save operation did not complete before the next user input hits > the server. I’ve searched my code for an unexpected reference to this > field name with no results. As I understand it, Django is single threaded > so I don’t know how this can happen.**** > > ** ** > > The Django code itself is not multithreaded -- it spawns no threads of its > own -- but that doesn't mean that your setup is single-threaded. That > depends entirely on how your web server is configured. Every production > environment I have seen uses processes or threads to serve multiple > requests simultaneously, which means that multiple instances of the Django > code are running at any given time.**** > > ** ** > > Django tries to be thread-safe, which is slightly different -- the code is > written such that multiple threads can co-exist without stomping all over > each other's data, at least at the Python level.**** > > ** ** > > At the database level, things are different again. This is probably where > your problems are coming from. If your database doesn't support isolation > through transactions (if you're using MyISAM tables on MySQL, basically), > then you are susceptible to problems like this. Database operations can and > will be interleaved, depending on when and how your web server decides to > schedule its threads.**** > > **** > > **** > > Has anyone seen similar behavior? I plan to upgrade next month anyway, > but could this be an artifact of the older Django or of MyISAM tables?**** > > ** ** > > I doubt that upgrading Django will solve anything, but I would recommend > upgrading your tables to InnoDB. The only reasons I know for sticking with > MyISAM are a requirement for speed over all else (including data > integrity), and to use the MySQL "full-text-search" feature.**** > > ** ** > > I’m not using transactions since I’m not an experienced DBA, but should > I?**** > > ** ** > > Happily, Django will take care of all of this for you; you don't have to > be a DBA, or even think about transactions most of the time. As long as > your database supports it, Django will automatically isolate each request > in its own transaction. If the view returns a response, the transaction > will be committed to the database, and if the view raises error, the > transaction will be rolled back automatically. In almost every case, this > behaviour will be exactly what you want.**** > > > **** > > ** ** > > -- > Regards, > Ian Clelland > <clell...@gmail.com>**** > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en.**** > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
