- Rewriting The OpenNTF Site With Jakarta EE, Part 1
- Rewriting The OpenNTF Site With Jakarta EE: REST
- Rewriting The OpenNTF Site With Jakarta EE: Data Access
- Rewriting The OpenNTF Site With Jakarta EE: Beans
In my last post, I talked about how I make use of Jakarta REST to handle the REST services in the new OpenNTF site I'm working on. There'll be more to talk about on that front when I get to the UI and my use of MVC. For now, though, I'll dive a bit into how I'm accessing NSF data.
I've been talking a lot lately about how I've been fleshing out the Jakarta NoSQL driver for Domino that comes as part of the XPages JEE project, and specifically how writing this app has proven to be an ideal impetus for adding specific capabilities that are needed for working with Domino. This demonstrates some of the fruit of that labor.
There are a few ways to interact with Jakarta NoSQL, and they vary a bit by database type (key/value, column, document, graph), but I focus on using the
Repository interface capability, which is a high-level abstraction over the pool of documents.
Before I get to that, though, I'll start with an entity object. Part of the heavy lifting that a framework like Jakarta NoSQL does is to map between a Java class and the actual data representation. In the SQL world, one would likely come across the term object-relational mapping for this, and the concept is generally the same. The project currently has a handful of such classes, and so the data layer looks like this:
The mechanism for mapping a class in JNoSQL is very similar to JPA:
@Entity("Release") at the top there declares that this class is a JNoSQL entity, and then the Domino driver uses
"Release" as the form name when creating documents and performing queries.
@Column("...") annotations map Java object properties to fields and attributes on the document.
@Id populates the field with the document's UNID, while
@Column does a named field. There's a special one there -
@Column(DominoConstants.FIELD_ATTACHMENTS) - that will populate the field with references to the document's attachments when present. In each of these cases, all of the heavy lifting is done by the driver: there's no code in the app that manually accesses documents or views.
The way I get access to documents mapped by these classes is to use the JNoSQL
Repository mechanism, by way of the extended
DominoRepository interface. They look like this (used here as an inner class for stylistic reasons, not technical ones):
Merely by creating this interface, I'm able to get access to the associated documents: I don't actually have to implement it myself. As seen in the last post, these interfaces can be injected into a bean or REST resource using CDI:
Naturally, there is implementation code for this repository, but it's all done with what amounts to "Java magic": proxy objects and CDI. That's a huge topic on its own, and it's pretty weird to realize that that's even possible, but it will have to suffice for now to say that it is possible and it works great.
When you create one of these repositories, you get basic CRUD capabilities "for free": you can create new documents, look up existing documents by ID, and modify or delete existing documents.
Beyond that, JNoSQL will do some lifting for you to give sensical implementations for methods based on their method signature in the absence of any driver-specific code. I'm making use of that here with
findByProjectName(String projectName, Sorts sorts). The proxy object that provides this implementation is able to glean that
String projectName refers to the
projectName field of the
ProjectRelease class, which is then mapped by annotation to the
ProjectName item on the back end. The
Sorts object is a JNoSQL type that allows you to specify one or more sort columns and their orders. When executed, this is translated to a DQL query like:
Sorts are specified, this is also run through
QueryResultsProcessor to create a QRP view with the given sort columns in a local temp database. Thanks to that, running the same query multiple times when the data hasn't changed will be very speedy.
You can customize these queries further by adding more parameters, or by using the
@Query annotation to provide a SQL-like query with parameters.
Since Domino is so view-heavy and DQL+QRP isn't quite at the level where you can just throw any old query+extraction at it and expect it to perform well, it made sense for me to add extensions to JNoSQL to explicitly target views as sources. I use them both here, in one case to efficiently retrieve view data without opening documents and in another in order to piggyback on an existing view used by the IP Tools services already deployed.
@ViewEntries("ReleasesByDate") annotation causes the
findRecent annotation to skip JNoSQL's normal interpretation of the method and instead be handled by the Domino driver directly. It will open that view and read entries based on the
Pagination rules sent to it (another JNoSQL object). Since the columns in this view line up to the item names in the documents, I'm able to get useful entity objects out if it without having to actually crack open the docs. In practice, I'll need to be careful when using this so as to not save entities like this back into the database, since not ALL columns are present in the view, but that's a reasonable caveat to have.
@ViewDocuments("IP Management\\Pending Releases") annotation causes
findPendingReleases to read full documents out of the named view, ignoring view columns. Eventually, I'll likely replace this with an equivalent query in JNoSQL's dialect, but for now it's more practical to just use the existing view like a stored query and not have to translate the selection formula to another mechanism.
The last thing to touch on with this repository is the
@RepositoryProvider annotation. The OpenNTF web site is stored in its own NSF, and then references several other NSFs, such as the projects DB, the blog DB (which is still based on BlogSphere), and the patron directory. The
@RepositoryProvider annotation allows me to tell JNoSQL to use a different database than the current one, and it does so by finding a matching CDI producer method that gives it a
lotus.domino.Database housing the documents and a high-privilege
lotus.domino.Session to create QRP views. In this app's case, that's this in another bean:
I'll touch on what the heck a
@Produces method is in CDI later, but for now you can take it for granted that this works. The
getProjectsDatabase() method that it calls is a utility method that opens the project DB based on some configuration documents.
I'll note with no small amount of pleasure that this bean that provides databases is one of the only two places in the app that actually reference Domino API classes at all, and the other instance is just to convert Notes names. I'm considering ways to remove this need as well, perhaps making it so that this producer only needs to provide a path to the target database and the name of a high-privilege user to act as, and then the driver would do the session creation and DB opening itself.
In the next post, I'll most likely talk about my use of CDI to handle the "managed beans" layer. In a lot of ways, that will just be demonstrating the way CDI makes the tasks you'd otherwise accomplish with XPages Managed Beans simpler and more code-focused, but (as the
@Produces annotation above implies) there's a lot more to it.