On 02/03/2017 11:59 AM, Octave J. Orgeron wrote:
Hi Mike,
Comments below..
Thanks,
Octave
On 2/3/2017 7:41 AM, Mike Bayer wrote:
On 02/02/2017 05:28 PM, Octave J. Orgeron wrote:
That refers to the total length of the row. InnoDB has a limit of 65k
and NDB is limited to 14k.
A simple example would be the volumes table in Cinder where the row
length goes beyond 14k. So in the IF logic block, I change columns types
that are vastly oversized such as status and attach_status, which by
default are 255 chars.
let me give you a tip on IF blocks, that they are a bit of an
anti-pattern. If you want a column type to do one thing in one case,
and another in another case, create an object that does the thing you
want:
some_table = Table(
'some_table', metadata,
Column('my_column', VARCHAR(255).with_variant(VARCHAR(50), 'ndb'))
)
I think we might want to look into creating a stub dialect called
'ndb' that subclasses mysql+pymysql. Treating ndb as a whole
different database means there's no longer the need for a flag in
oslo.db, the 'ndb' name would instead be interpreted as a new backend
- the main thing would be ensuring all the mysql-appropriate hooks in
oslo.db are also emitted for ndb, but this also gives us a way to pick
and choose which hooks apply. It seems like there may be enough
different about it to separate it at this level.
Not sure if people on the list are seeing that we are simultaneously
talking about getting rid of Postgresql in the efforts to support only
"one database", while at the same time adding one that is in many ways
a new database.
This is an interesting approach as it would significantly reduce the
amount of code in my patches today. Do you have any pointers on where
this should be implemented as a stub? Would we have to take different
approaches for SQL Alchemy vs. Alembic?
there are simple plugin points for both libraries.
One of the popular 3rd party dialects right now is the
sqlalchemy-redshift dialect, which similarly to a lot of these dialects
is one that acts 95% like a "normal" dialect, in this case postgresql,
however various elements are overridden to provide compatibility with
Amazon's redshift. The overlay of an NDB style dialect on top of
mysql would be a similar idea. The SQLAlchemy plugin point consists
of a setuptools entrypoint (see
https://github.com/sqlalchemy-redshift/sqlalchemy-redshift/blob/master/setup.py#L40
,
https://github.com/sqlalchemy-redshift/sqlalchemy-redshift/blob/master/sqlalchemy_redshift/dialect.py#L315)
and for Alembic, once the dialect is imported you define a special
Alembic class so that Alembic sees the engine name also (see
https://github.com/sqlalchemy-redshift/sqlalchemy-redshift/blob/master/sqlalchemy_redshift/dialect.py#L19).
In this case the NDB dialect seems like it may be a little bit of a
heavy solution but it would solve lots of issues like the "mysql_engine"
flag would no longer be in conflict, special datatypes and naming
schemes can be pulled in, etc. It would at least allow conditionals
against "ndb" in Openstack projects to switch on the same kind of
criteria that they already do for sqlite/postgresql/mysql.
It is possible for the ndb "stub dialect" to be at least temporarily
within oslo.db, however the way to go about this would be to start
getting ndb working as a proof of concept in terms of gerrit reviews.
that is, propose reviews to multiple projects and work at that level,
without actually merging anything. We don't merge anything until it's
actually "done" as a tested and working feature / fix.
--
Oracle <http://www.oracle.com/>
Octave J. Orgeron | Sr. Principal Architect and Software Engineer
Oracle Linux OpenStack
Mobile: +1-720-616-1550 <tel:+17206161550>
500 Eldorado Blvd. | Broomfield, CO 80021
Certified Oracle Enterprise Architect: Systems Infrastructure
<http://www.oracle.com/us/solutions/enterprise-architecture/index.html>
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
