I don't think I ever used MyISAM tables with a WO app. I have seen corrupted data with InnoDB tables and WO usage though. For the rest, they might have been MyISAM used from some PHP web crap, but the thing is: the SQL stored the thing and some historic data gets corrupted. That was the issue we had. I can't recall exactly enough to blame it completely on MySQL, but I stopped using it and I had never ever again any issues with corrupt data (95% PostgreSQL, 5% FrontBase usage).
FrontBase has the issue that you can easily kill the server with bad input. This can't happen with PostgreSQL as you get your own backend for each connection. Between the three databases MySQL, PostgreSQL, and FrontBase, I've used PostgreSQL the most and with the most success and least amount of trouble. I'd love to see a multi master clustering solution for it though that actually works and is not a piece of shit. Guido -- http://www.event-s.net On 3. Dec. 2009, at 17:04 , Kieran Kelleher wrote: > I have seen screwed up data from people using default MyISAM tables. Not > transactional tables. So basically if your EC saveChanges fails, there is no > rollback, so now you have a half-committed save ..... yes, using the default > MyISAM engine *will* screw up your data big time .... and that is a problem > with the engineer who configured the thing ;-) > > On Dec 3, 2009, at 7:08 PM, Guido Neitzer wrote: > >> I saw some serious issues with MySQL and migrations lately, but haven't >> checked where the actual reason might be. It looked like you can't create >> table, then call existingTableNamed as this will return null. Also it >> actually created tables and didn't roll back when the migration failed. I >> don't know whether something was set up incorrectly, as I'm personally not >> using MySQL for reasons that might not be valid anymore. I also found it way >> more natural to use and it is better supported by the combination WebObjects >> / Wonder (wonder why ... :-) ). >> >> One more reason which always kept me away from MySquirrel: It let me down a >> couple times with screwed up data in the 3.x and 4.x times. Don't know what >> happened back then (long ago), but the safety wasn't there ... might have >> also been my inability to use it correctly. Interesting enough I never had >> these issues with PG. >> >> Guido >> >> -- >> http://www.event-s.net >> >> On 3. Dec. 2009, at 15:09 , Mike Schrag wrote: >> >>> with MySQL 5, I don't think there's any reason to believe it's less of a >>> database ... in particular, mysql's has an actual clustering implementation >>> whereas pg has a failure pile in a sadness bowl. >>> >>> http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL >>> >>> this seems to be a reasonably up-to-date comparison >>> >>> ms >>> >>> On Dec 3, 2009, at 5:58 PM, Kieran Kelleher wrote: >>> >>>> Miguel, anyone, please enlighten me as to what specifically is wrong with >>>> using MySQL InnoDB as a database for WO because I have not seen any >>>> problem, but then I have not used PostgreSQL or FrontBase either - so >>>> maybe I don't see a problem that I should be concerned about. >>>> >>>> -Kieran >>>> >>>> On Dec 3, 2009, at 5:41 PM, Miguel Arroz wrote: >>>> >>>>> Hi! >>>>> >>>>> On 2009/12/03, at 22:32, Kieran Kelleher wrote: >>>>> >>>>>>>> I create new OSCs for most background tasks. The one thing is that I >>>>>>>> dispose() on it at the end of the task .... and the dispose() is only >>>>>>>> useful if you use ERXJDBCAdaptor is used since the regular WO 5.3 jdbc >>>>>>>> adaptor opens two connections for every OSC and leaves the stupid >>>>>>>> things open forever. ERXJDBCAdaptor only opens one db connection and >>>>>>>> releases it when u call dispose() IIRC. >>>>>>> >>>>>>> Dude! >>>>>>> <http://terminalapp.net/webobjects-postgresql-and-db-growing-and-growing/> >>>>>>> ;) >>>>>> >>>>>> Dude! www.mysql.com - innodb (or cluster NDB) .... doesn't "grow and >>>>>> grow" (and it is not a "toy", no matter what Chuck says ;-) ) >>>>> >>>>> No, it's a disaster! ;) >>>>> >>>>> The "growing" is a side effect of leaving the transaction opening that >>>>> happens on PostgreSQL due to its architecture, but the point is the same, >>>>> do what I say there to avoid the dumb connection. :) >>>>> >>>>> Yours >>>>> >>>>> Miguel Arroz >>>>> >>>> >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>> Help/Unsubscribe/Update your Subscription: >>>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com >>>> >>>> This email sent to msch...@mdimension.com >>> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/guido.neitzer%40gmail.com >>> >>> This email sent to guido.neit...@gmail.com >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists%40mac.com >> >> This email sent to kieran_li...@mac.com > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
