hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Marc Spaggiari <jean-m...@spaggiari.org>
Subject Re: Data types stage 1 is ready for reivew
Date Sat, 03 Aug 2013 18:24:45 GMT
This is my preferred approach. Many users don't want to have any types on
the data because they might already have their own format, or just because
they don't need it.

So we should not enforce clients to use it.

JM

2013/8/3 Nick Dimiduk <ndimiduk@gmail.com>

> On Sat, Aug 3, 2013 at 10:33 AM, Michael Segel <msegel_hadoop@hotmail.com
> >wrote:
>
> > How do you plan on enforcing data types within the engine?
> >
>
> Data types, at this point, are a client-side feature, not enforced by the
> engine in anyway.
>
>  On Aug 1, 2013, at 10:57 PM, Matt Corgan <mcorgan@hotpads.com> wrote:
> >
> > > Looks great to me.  Without the strict dependencies on hadoop or hbase
> > > it'll be easy to pull into its own standalone module or new project if
> > > there's demand.
> > >
> > >
> > > On Thu, Aug 1, 2013 at 6:30 PM, Nick Dimiduk <ndimiduk@gmail.com>
> wrote:
> > >
> > >> Finally-for-real-this-time patches posted. I'll take your +1's any
> time
> > now
> > >> ;)
> > >>
> > >> Thanks,
> > >> Nick
> > >>
> > >> On Wed, Jul 24, 2013 at 11:27 AM, Nick Dimiduk <ndimiduk@gmail.com>
> > wrote:
> > >>
> > >>> Hi everyone,
> > >>>
> > >>> As of yesterday, I've posted "final" patched on both HBASE-8201<
> > >> https://issues.apache.org/jira/browse/HBASE-8201>and
> > >>> HBASE-8693 <https://issues.apache.org/jira/browse/HBASE-8693>.
The
> > >> former
> > >>> specifies on-disk format and the latter is the user-facing API. If
> > you've
> > >>> already left me a review, thank you; please have another look at
> these
> > >>> patches. If you have an opinion here and haven't voiced it, we're
> > >>> approaching the "forever hold your peace" part of the ceremony.
> > >>>
> > >>> Thanks,
> > >>> Nick
> > >>>
> > >>>
> > >>> On Wed, Jul 17, 2013 at 9:33 AM, Nick Dimiduk <ndimiduk@gmail.com>
> > >> wrote:
> > >>>
> > >>>> Thanks for having a look. If you don't mind terribly, I responded
to
> > >> your
> > >>>> comments on JIRA [0].
> > >>>>
> > >>>> Thanks,
> > >>>> Nick
> > >>>>
> > >>>> [0]:
> > https://issues.apache.org/jira/browse/HBASE-8693#comment-13711250
> > >>>>
> > >>>>
> > >>>> On Wed, Jul 17, 2013 at 1:42 AM, Matteo Bertozzi <
> > >> theo.bertozzi@gmail.com
> > >>>>> wrote:
> > >>>>
> > >>>>> I was looking at the HBASE-8693 patch, and looks good to me
for the
> > >>>>> primitive types.
> > >>>>> but I can't see how do you plan to evolve stuff like the struct.
> > >>>>> By "evolve" I mean add/remove fields, or just query it with
a
> subset
> > of
> > >>>>> fields.
> > >>>>> the fields don't have an id, and on read you must specify all
of
> them
> > >> in
> > >>>>> the same order as you've used for write.
> > >>>>> (but maybe is just an immutable/fixed list of fields, and I'm
ok
> with
> > >>>>> just
> > >>>>> adding that info to the comment on top of the class)
> > >>>>>
> > >>>>>
> > >>>>> Matteo
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On Wed, Jul 17, 2013 at 12:39 AM, Nick Dimiduk <ndimiduk@gmail.com
> >
> > >>>>> wrote:
> > >>>>>
> > >>>>>> New patch posted. What do you think about the new isSkippable()
> and
> > >> the
> > >>>>>> associated limitation in Struct?
> > >>>>>>
> > >>>>>> I also posted some "dogfeed" per Enis's suggestion.
> > >>>>>>
> > >>>>>> -n
> > >>>>>>
> > >>>>>> On Fri, Jul 12, 2013 at 1:38 PM, Stack <stack@duboce.net>
wrote:
> > >>>>>>
> > >>>>>>> On Fri, Jul 12, 2013 at 1:10 PM, Enis Söztutar <enis@apache.org>
> > >>>>> wrote:
> > >>>>>>>
> > >>>>>>>> Did some chatting with Nick today.
> > >>>>>>>>
> > >>>>>>>> I think it is really important to get this right,
and for that
> we
> > >>>>> would
> > >>>>>>>> definitely need more eyes towards it. The current
patch set is
> > >> in a
> > >>>>>> good
> > >>>>>>>> state to bolster the discussion.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>> I'll do another pass (Kicking others to give it a looksee
too).
> > >>>>>>> St.Ack
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>
> > >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message