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 [Quadient] Quadient® a: Utrechtseweg 310, Building H31 6812 AR Arnhem The Netherlands w: www.quadient.com<https://www.quadient.com/> e: a.seijk...@quadient.com<mailto:a.seijk...@quadient.com> [https://go.pardot.com/l/68752/2015-06-17/dymgk/68752/22130/Twitter_icon_2.png] <https://twitter.com/Quadient> [https://go.pardot.com/l/68752/2015-06-17/dymg7/68752/22126/LinkedIn_icon_2.png] <https://www.linkedin.com/Quadient/> [https://go.pardot.com/l/68752/2015-06-17/dylq7/68752/22120/Facebook_icon_2.png] <https://www.facebook.com/Quadient> [https://go.pardot.com/l/68752/2015-06-17/dymgy/68752/22132/YouTube_icon_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
