Open Stack

On 11/12/2012 07:55 AM, Ionuț Arțăriși wrote:
> Hi,
>
> I submitted a patch for review last week[1] which started a discussion
> about implementing sqlalchemy dialect specific datatypes
> (e.g. postgresql, mysql etc.).
>
> I think it would be great to abstract some common datatypes (such as for
> ip addresses) so we can then add custom validations or use different
> backend datatypes where that makes sense.
>
> The way the IPAddress is implemented should be pretty straightforward and
> very backwards compatible (the INET datatype acts as a string for basic
> operations). Just defining a new datatype:
>
> IPAddress = lambda: String(255).with_variant(postgresql.INET(),
> 'postgresql')
>
> which can then be used instead of the string like so:
>
> access_ip_v4 = Column(IPAddress())
>
> I guess now there's the question of where we want to store these
> custom dataypes' implementations. Would it be enough to have a datatypes.py
> module in there and have all our custom types inside?
>
>
> [1] https://review.openstack.org/#/c/15566/

I think the overall goal is a good one. But, I don't think the code 
should live in nova/db/sqlalchemy/models.py though. It's good that 
models.py doesn't know about SQL dialects today, and I think we should 
keep it that way.

My feeling is the optimization proposal needs to come in a way that lets 
us keep those optimizations out of the generic model layer. It doesn't 
look so bad when you have a few tweaks for postgresql, but once you do 
the same for mysql, and possibly commercial dbs, it gets ugly fast if it 
isn't segmented out.

	-Sean

-- 
Sean Dague
IBM Linux Technology Center
email: sdague at linux.vnet.ibm.com
alt-email: sldague at us.ibm.com