If we do PInteger, etc., do we have to make DInteger for Drill types, IInteger for Impala types and TInteger for Trafodion types? St.Ack
On Mon, Dec 8, 2014 at 7:01 PM, Nick Dimiduk <ndimi...@gmail.com> wrote: > Okay, I've done as you suggested with PInteger, PFloat, &c and cleaned out > all the funky java.lang import handling. This has brought the patch down in > size significantly. I can probably reduce the patch size further still if I > rename the instances, like Binary.INSTANCE to BINARY and use static imports > everywhere the enum was used previously. I've also got the full test suite > passing. My use of equals vs == is still inconsistent, but I'm using > singletons everywhere, so this isn't causing any problems. I plan to clean > that up next. I've squished the branch into a single patch and pushed to my > github. Please have a look if you find a few more minutes. I guess it's > time to open a JIRA now too. > > > https://github.com/ndimiduk/phoenix/commit/f97047b0f3e2cc7c4f60625b9eda88987156af92 > > On Mon, Dec 8, 2014 at 5:52 PM, James Taylor <jamestay...@apache.org> > wrote: > > > +1 on using PInteger, PLong, etc. to disambiguate. > > > > +1 on limiting to purely structural changes initially. > > > > If it can be b/w compatible (with all tests passing), I'd vote to put > > it in 4.x and master. The longer we can keep 4.1 and master in sync, > > the better. > > > > On Mon, Dec 8, 2014 at 2:44 PM, Nick Dimiduk <ndimi...@gmail.com> wrote: > > > On Thu, Dec 4, 2014 at 11:11 AM, James Taylor <jamestay...@apache.org> > > > wrote: > > > > > >> Wow, this is fantastic, Nick. Big +1. > > >> > > > > > > Thanks for the enthusiasm James :) > > > > > > You're welcome to coopt and use the type-system branch in the Apache > > >> Phoenix git repo if that's helpful. > > >> > > > > > > I'd forgotten about that one. Will keep it in mind. > > > > > > 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. > > >> > > > > > > I've been able to preserve the enum ordering, at least in theory. I'm > > still > > > working through failing tests. > > > > > > 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. > > > > > > > > > Right. For now, I'm trying to keep the patch as limited as possible to > > > structural changes. We can go back after and refactor, reduce > > duplication, > > > etc. > > > > > > 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. > > >> > > > > > > I've run into a couple bugs because of this already, it seems to have > > made > > > things fragile. OTOH, I didn't want to introduce PInteger, PLong, &c. > > Maybe > > > I'll go back to that, unless you have a better suggestion. > > > > > > 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? > > > > > > > > > Yes, as would I, at least with the big "bust it up" patch. Right now > I'm > > > working against master. Is there any reason I should be back porting it > > to > > > 3.x or 4.x? > > > > > > On Wed, Dec 3, 2014 at 1:45 PM, Nick Dimiduk <ndimi...@gmail.com> > 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 <ndimi...@gmail.com> > > >> 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 > > >> >> > > >> > > >
