Wow, this is fantastic, Nick. Big +1. You're welcome to coopt and use the type-system branch in the Apache Phoenix git repo if that's helpful.
Any thoughts on how we can manage backward compatibility? Types are identified by their ordinal position in the enum right now (that's what the client typically sends to the server). If we can maintain that, we might be able to pull it off. By breaking it up the way you've done, we should be able to get rid of much of the copy/paste code that was required because we couldn't have intermediate base types. For example, we can introduce a BaseArrayType and move the array code their (it's more or less identical for all the array sub types). The same would apply to numeric types Byte, Short, Integer, and Long: we could have a BaseNumberType and remove a bunch of duplicate code. Minor nit: it'd be nice if the type class names didn't conflict with the Java built-in types so that we don't have to fully qualify them on usage. It'd be great to get this in sooner rather than later, as it's going to be tricky to keep your branch in sync with the Apache ones given how all encompassing the change is. Any thoughts on this? Thanks, James On Wed, Dec 3, 2014 at 1:45 PM, Nick Dimiduk <[email protected]> wrote: > Here's my progress in the effort of breaking up the PDataType enum. > > https://github.com/ndimiduk/phoenix/commits/WIP-DataType > > On Wed, Dec 3, 2014 at 10:36 AM, Nick Dimiduk <[email protected]> wrote: > >> Heya, >> >> I'd like to start a conversation around the idea of user-defined types. I >> think this is a very powerful point of extension for a database and will >> help foster the growing community around Phoenix. It will also facilitate >> enhanced interoperability between Phoenix and other HBase applications. >> >> I've started work on a patch to bust the PDataType enum. Rather than a >> fixed set of types, PDataType becomes an interface with the various >> implementations. Probably the next step would be to extend the grammar to >> support new type names and constants. After that, adding a syntax for >> registering types at runtime. >> >> Right now this is an experiment. I'm curious if there's interest for this >> kind of thing in Phoenix. I draw inspiration from the extensibility of >> PostgreSQL, with a notable extension being PostGIS. As an example, I'd love >> to see this feature working such that we can define a Phoenix schema over >> an existing OpenTSDB table. It'll take some work to get there, but I think >> it's worth while to help folks migrate from existing HBase schema over to >> Phoenix. >> >> Thoughts? >> >> Thanks, >> Nick >>
