Open Stack

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 <mordred at inaugust.com> 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130710/6a2c2b52/attachment.html>