I know Reuven, but when you check what it does, it is exactly the same and the current work will be to replace by the schema work so better to avoid a round trip of work which will be throw away in any case. Also note that current structure is flat and very limiting for modern SQL so the alignment of both will be beneficial to beam in any case so better to ensure all parts of the projects move in the same direction instead of requiring yet another layer of conversion, no?
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> 2018-02-03 16:32 GMT+01:00 Reuven Lax <re...@google.com>: > This is a core part of SQL which is ongoing. > > On Feb 2, 2018 11:45 PM, "Romain Manni-Bucau" <rmannibu...@gmail.com> > wrote: > >> Hi >> >> Shouldnt the discussion on schema which has a direct impact on this >> generic container be closed before any action on this? >> >> >> Le 3 févr. 2018 01:09, "Ankur Chauhan" <an...@malloc64.com> a écrit : >> >>> ++ >>> >>> On Fri, Feb 2, 2018 at 1:33 PM Rafael Fernandez <rfern...@google.com> >>> wrote: >>> >>>> Very strong +1 >>>> >>>> >>>> On Fri, Feb 2, 2018 at 1:24 PM Reuven Lax <re...@google.com> wrote: >>>> >>>>> We're looking at renaming the BeamRecord class >>>>> <https://github.com/apache/beam/pull/4550>, that was used for >>>>> columnar data. There was sufficient discussion on the naming, that I want >>>>> to make sure the dev list is aware of naming plans here. >>>>> >>>>> BeamRecord is a columnar, field-based record. Currently it's used by >>>>> BeamSQL, and the plan is to use it for schemas as well. "Record" is a >>>>> confusing name for this class, as all elements in the Beam model are >>>>> referred to as "records," whether or not they have schemas. "Row" is a >>>>> much >>>>> clearer name. >>>>> >>>>> There was a lot of discussion whether to name this BeamRow or just >>>>> plain Row (in the org.apache.beam.values namespace). The argument in favor >>>>> of BeamRow was so that people aren't forced to qualify their type names in >>>>> the case of a conflict with a Row from another package. The argument in >>>>> favor of Row was that it's a better name, it's in the Beam namespace >>>>> anyway, and it's what the rest of the world (Cassandra, Hive, Spark, etc.) >>>>> calls similar classes. >>>>> >>>>> RIght not consensus on the PR is leaning to Row. If you feel strongly, >>>>> please speak up :) >>>>> >>>>> Reuven >>>>> >>>>
