The "P" before these type names are to prevent conflicts with Java types. For example java.lang.Integer and org.apache.phoenix.schema.Integer conflict. Rather than do import hackery, it seems better IMHO to name them slightly differently.
The question about all these products agreeing on a type system is a different, bigger issue. Nick's work here is only making that easier (at least technically speaking :-) ) by making the Phoenix type system more extensible. Thanks, James On Tue, Dec 9, 2014 at 2:12 PM, Nick Dimiduk <ndimi...@gmail.com> wrote: > This work is entirely within Phoenix: org.apache.phoenix.schema.PInteger. > Those projects can do as they like. > > On Tue, Dec 9, 2014 at 12:53 PM, Stack <st...@duboce.net> wrote: > >> 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 >> > > >> >> >> > > >> >> > > >> > >>
