far be it from me to ask. but isn't this something that should be addressed in oslo common db, and made configurable as an class definition or method argument?
-matt On Tue, Jul 9, 2013 at 9:27 AM, Monty Taylor <[email protected]> wrote: > > > On 07/09/2013 11:21 AM, Clint Byrum wrote: > > >>> You may want to update your snark! MySQL has its warts which are pretty > >>> easy to take shots at, but it has been a "real" ACID compliant database > >>> for well over a decade. > >> My snark is more recently generated than that. There are plenty of > >> places where MySQL has fallen down. > >> > >> InnoDB support was not mandatory, and without it, MySQL was not really > >> ACID compliant. Using InnoDB was troublesome enough that the RHEL 6 > >> version of MySQL defaults to MyISAM. > >> > > > > Its not so much that it was troublesome to use InnoDB as it was that > > people were used to MyISAM's few mis-features (fulltext and delayed > > inserts mostly) and needed a long warning (run up to 5.5) that the > > default was changing. Before 5.5 was released, Drizzle _completely > > removed_ MyISAM because it causes way more problems than it solves. > > Let's try to avoid snarky database flame wars. There are enough of us in > this community with massive experience in each database that they are > useless to have. > > MySQL and PostGres are both lovely databases that are both completely > valid choices for production. If anyone out there wants to have a beer > and attempt to convince me otherwise, you are welcome to. You will not > succeed. All snark aside, the current body of evidence for the current > state of both databases will vastly outweigh any snark. The_historical_ > body of evidence for both databases has ridiculous warts, but is pointless. > > That said, we, as a project, seem to have made the decision that we find > it important to support any biases you may have as a deployer by > supporting multiple database backends via SQLalchemy. However, OpenStack > is intended to be something that can be used for real large-scale > production workloads. Most large scale database apps are NOT written in > a database agnostic manner, because every database out there has > performance quirks that have to be considered, and has a different set > of tools for making things work. > > How do we deal with that dichotomy? I think it might behoove us to > figure out a _sensible_ way to allow for engine-specific overrides of > sqlalchemy behavior where appropriate. The sqlaclchemy code should be > totally functional and correct, but there are clearly times when a > single well-crafted query, or taking advantage of a database-specific > extension could make a massive difference for a large deploy. > > I don't think we should start peppering our code with a bunch of ifs. If > we want this, we need an understandable, sensible and repeatable > mechanism for engine-specific optimizations. Something tells me this > will not be the last time the question comes up. > > Monty > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
