As a follow-on ticket to 4605, this means adding the support for altering a table more easily. Specifically, this means doing something like:

alter("table").addCoprocessor(…)
alter("table").addColumnFamily(…)
…

and then for constraints, something like:

alter("table").addConstraint(…)
alter("table").enableConstraints
…

with those methods being added dynamically by a 'constraint module' in the jruby code. This would also serve as an example for how further shell extension can be done in a modular manner.

This ticket may also become a more major revamp for the how the shell works, e.g. dropping into a table context, etc as described in the discussion.

Adding link to original constraints ticket.

Linking to jira for getting an individual table. The original pain around this was in that constraints only make sense for a single table, so we could just dynamically tie it to a table.

By dynamically, I was thinking either via opening the Table class back up to add methods or doing a dynamic lookup of all classes in a table-extensions folder and including them in the Table class.

Jesse Yates Can you add a release note for how and when to use this feature (folks have been wondering!). Thanks boss.

stack, you mean for the constraint stuff in general? The shell support never got finished...

Hey Jesse Yates, this came from me asking internally. I was wondering what the status is here. The idea seems interesting to developers, yet it is all in the server package and flagged Private. Should this not be accessible, at least LimitedPrivate? But is it complete enough to be used? I understand that the shell stuff is not complete, I found the JIRA. But that also discourages to use it at all. As for context, I am working on the 2nd ed of my book and was wondering if I should include this or not. Please let us know.

Hmm, I'm not sure when they got put under the private annotation. Indeed was meant to be something used by users, not just limited to internal use (of which there is none, AFAIK).

Should this not be accessible, at least LimitedPrivate? But is it complete enough to be used?

Yes, and yes. The tests are still running and passing (e.g. TestConstraint.java), so constraints at least work. So it can be used, with some caveats.

It has two main issues: (1) you still have to deploy a jar to the server that contains the constraint (ala coprocessors or filters), and (2) its not useful for many cases because as the docs say:

Further, {@link Constraint Constraints} should probably not be used to enforce cross-table references as it will cause tremendous write slowdowns, but it is possible.

Obviously, there is no way around the second one, and the interface actually goes out of its way to not allow you access to an HTable, to prevent this kind of thing.

However, the flip side is that you have very limited utility. It becomes useful for toy examples, but in real life its really limited to use. I don't know of any users actively using constraints (though there was some interest when they first came out).

Things that could be added to increase utility are: a limited HTable interface that only accesses the local region and just for reads; a basic set of constraint processors that uses the table properties to configure certain constraints (e.g. all values must remain > 0); easy shell support.

Your call if you want to include it - they can be useful, but no one has actually used them I'm happy to write code/do reviews/commit improvements, if people actually want them, but until there is an actual user who wants them, I'm reluctant to put any more work into it.