The "Wide Column (store)" term comes from this article: https://db-engines.com/en/article/Wide+Column+Stores.
Based on that article, I'm not sure if we should also use it for MongoDB, CouchDB and Elasticsearch, but it seems like an option to introduce it and use it for both Cassandra and HBase, we may have to rethink the names of the methods on the class (or maybe interface) in that case a bit more, because Cassandra is implemented in a different manner/structure then HBase. Kind regards, Arjan Seijkens -----Original Message----- From: Kasper Sørensen <i.am.kasper.soren...@gmail.com> Sent: Wednesday, May 23, 2018 4:59 PM To: dev@metamodel.apache.org Subject: Re: Extending HBase support I like the idea of reusing the WideColumn class also for Cassandra. Is "Wide Column" a term that you've encountered elsewhere, or did you make that up? I kinda like it, but would want to consider naming as important. One piece of perspective too is that some databases (notably MongoDB, CouchDB, ElasticSearch) support "wide rows" in a way, meaning that any particular row may contain additional fields outside of the norm. Maybe we could introduce both WideRow and WideColumn interfaces to support that sort of behaviour? Kasper 2018-05-22 7:25 GMT-07:00 Arjan Seijkens <a.seijk...@quadient.com>: > Hi, > > > > In the context of an internship we have been working on extending > HBase support for MetaModel, mainly focusing on adding write support. > > > > Right now there is a pull request for this on a MetaModel fork, which > can be found here: > https://github.com/GerardDellemann/metamodel/pull/2. Note that we will > probably have to replace this pull request with a new one to be able to merge > it into MetaModel master instead of the fork. > > > > There is one specific change within this pull request which I would > like to discuss here. > > > > Within this pull request we introduce the HBaseColumn class, which > extends the AbstractColumn class and which represents a column in an HBase > table. > We introduced this class because HBase uses a Wide column store for > it's database model, which works in a different manner as relational > database columns. > > > > In its current state the HBaseColumn class has two important new methods: > > - HBaseColumn#getColumnFamily() > - HBaseColumn#getQualifier() > > > > From this perspective each Column always has a Column family and > optionally has a qualifier. If a Column has both a Column family and a > qualifier, we are able to get a specific value from a table row based > on that column. If a Column only has a Column family, we don't know > which qualifiers it has, which can be a typical use case because > qualifiers are dynamic and can be different for each row, then when > getting the value from a table row base on that column, we get a list of all > values. > > > > This is how it's implemented now in the pull request. > > > > I would like your opinion on this, so fire away. Some considerations: > > - Maybe we shouldn't call the class HBaseColumn, but rename it to > WideColumn instead and do some more renaming of the methods, so it can be > reused later on for Cassandra. > - In the current implementation the HBaseColumn supports both using it > with and without a qualifier, which causes different behaviors, is this > desirable, or should we create two different classes? > > > > Furthermore all other feedback on the pull request is welcome, but you > can also wait with that until we replace it with a pull request to > actually merge it into MetaModel (instead of into the fork). > > > > Kind regards, > > > > Arjan Seijkens > > *Technical Lead Quadient DataCleaner* > > Research & Development > > > > [image: Quadient] > > *Quadient®* > > a: > > Utrechtseweg 310, Building H31 > <https://maps.google.com/?q=Utrechtseweg+310,+Building+H31+%0D%0A+6812 > +AR+Arnhem+%0D%0A+%0D%0A+The+Netherlands&entry=gmail&source=g> > 6812 AR Arnhem > <https://maps.google.com/?q=Utrechtseweg+310,+Building+H31+%0D%0A+6812 > +AR+Arnhem+%0D%0A+%0D%0A+The+Netherlands&entry=gmail&source=g> > > The Netherlands > <https://maps.google.com/?q=Utrechtseweg+310,+Building+H31+%0D%0A+6812 > +AR+Arnhem+%0D%0A+%0D%0A+The+Netherlands&entry=gmail&source=g> > > w: > > www.quadient.com e: a.seijk...@quadient.com > > > > [image: > https://go.pardot.com/l/68752/2015-06-17/dymgk/68752/22130/Twitter_icon_2.png] > <https://twitter.com/Quadient> [image: > https://go.pardot.com/l/68752/2015-06-17/dymg7/68752/22126/LinkedIn_icon_2.png] > <https://www.linkedin.com/Quadient/> [image: > https://go.pardot.com/l/68752/2015-06-17/dylq7/68752/22120/Facebook_icon_2.png] > <https://www.facebook.com/Quadient> [image: > https://go.pardot.com/l/68752/2015-06-17/dymgy/68752/22132/YouTube_ico > n_2.png] <https://www.youtube.com/channel/UCdOGV3K4rE7t9dW7A7JNN7w> > > > > The information contained in this e-mail is intended only for the > individual to whom it is addressed. It may contain privileged and > confidential information. If you have received this message in error > or there are any problems, please notify the sender immediately and > delete the message from your computer. The unauthorized use, > disclosure, copying or alteration of this message is forbidden. > Quadient and/or its worldwide subsidiaries will not be liable for > direct, special, indirect or consequential damage as a result of any > virus being passed on, or arising from alteration of the contents of this > message by a third party. > > > > Quadient, Max Höggerstrasse 6, CH-8048 Zurich > <https://maps.google.com/?q=Max+H%C3%B6ggerstrasse+6,+CH-8048+Zurich&e > ntry=gmail&source=g> > > >
