HBX-2996 New module containing natural language building blocks

[mbladel]

https://hibernate.atlassian.net/browse/HBX-2996

This introduces the basic components, as well as some first very simple test cases. It will most likely need some refinement, but it starts making these building blocks available for other projects to play around with. cc @yrodiere

[yrodiere]

Thanks, looks nice! I added a few comments below.

[yrodiere]

I'd be very careful about security claims. We know exposing this to end users gives them extensive access to the database. We think it's limited to reads and to the parts of the DB schema that are actually mapped, but a simple eval(<SQL>) function in HQL could bring the whole "security" down.

So, IMO we need to:

1. Document potential security risks, and clarify this is meant to be exposed in "back-office" scenarios.
2. Plan for a (future) security assessment.
3. Be conservative in our security-related claims in the meantime.

Suggested change

	* It leverages Hibernate ORM's mapping models, query language, cross-platform support and
	* enhanced security features to make access to information stored in relational databases
	* It leverages Hibernate ORM's mapping models, query language, cross-platform support and
	* read/write separation to make access to information stored in relational databases

[mbladel]

I agree with the sentiment here. Though I believe read/write separation isn't the right language, what I mean is it leverages Hibernate-specific features that improve security: restricted access to mapped objects, intrinsic validation of HQL queries, existing filters/restriction on data, et.al. Not sure how to express that in a "catchy" and concise way, maybe "built-in data restrictions"?

So, IMO we need to:

1. Document potential security risks, and clarify this is meant to be exposed in "back-office" scenarios.
2. Plan for a (future) security assessment.
3. Be conservative in our security-related claims in the meantime.

Sure, so the only actionable point here is 1. Where would we put such documentation?

[yrodiere]

features that improve security: restricted access to mapped objects, intrinsic validation of HQL queries, existing filters/restriction on data, et.al. Not sure how to express that in a "catchy" and concise way, maybe "built-in data restrictions"?

Works for me.

Sure, so the only actionable point here is 1. Where would we put such documentation?

I'd say in the Hibernate Tools docs? Problem is, @koentsje is still working on moving that back from JBoss Tools. So you'll probably need to handle that in a follow-up PR.

In the meantime, Koen, would it be possible for you to merge an initial version of that documentation, so that we can build on it? It can be almost empty and populated afterwards, that's not a problem IMO.

[yrodiere]

LGTM, thanks!

[yrodiere]

features that improve security: restricted access to mapped objects, intrinsic validation of HQL queries, existing filters/restriction on data, et.al. Not sure how to express that in a "catchy" and concise way, maybe "built-in data restrictions"?

Works for me.

Sure, so the only actionable point here is 1. Where would we put such documentation?

I'd say in the Hibernate Tools docs? Problem is, @koentsje is still working on moving that back from JBoss Tools. So you'll probably need to handle that in a follow-up PR.

In the meantime, Koen, would it be possible for you to merge an initial version of that documentation, so that we can build on it? It can be almost empty and populated afterwards, that's not a problem IMO.