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