Strange behaviour on findById

[monstermichl]

Hey Jesse, I've encountered a strange behavior when using findById with the repository described here. Even though I gave the Entities specific names (see code) and I query by id - for example from the Artist table a customer ID - I get an entry from the Customer table but wrapped into an Artist instance somehow (hopefully this is understandable). So I query e.g. artistRepository.findById(any-customer-id), an Artist instance is returned but the object returned is actually a customer. Is that on purpose? Does Entity("name") have an effect? Maybe this has already been fixed. we're using version 2.9.

@Entity("Artist")
public class Artist implements IDominoDocumentEntity {

    @Id
    private String _uid;

    @Column("artistId")
    private String _id;

    @Column("deleted")
    private byte _deleted; /* Use byte value as boolean seems to cause problems (stored as N or Y but the back-conversation doesn't work for some reason). See also https://github.com/OpenNTF/org.openntf.xsp.jakartaee/issues/96. */

@Entity("Customer")
public class Customer implements IDominoDocumentEntity {

    @Id
    private String _uid;

    @Column("customerId")
    private String _id;

    @Column("deleted")
    private byte _deleted; /* Use byte value as boolean seems to cause problems (stored as N or Y but the back-conversation doesn't work for some reason). See also https://github.com/OpenNTF/org.openntf.xsp.jakartaee/issues/96. *

[monstermichl]

I added a method to query from a desired repository and found out that, if the mapping was done wrong, the internally used ID (not the UID), which we require on our objects. is not being set. So I'm checking if the ID is null to determine if the currect table was used. But still this is weird 😅

protected <U extends IDominoDocumentEntity> U _findById(CommonDominoDocumentRepository<U> repository, String id) {
    U document = null;
    Optional<U> documentOptional = repository.findById(id);

    if (documentOptional.isPresent()) {
        document = documentOptional.get();

        /* Make sure the mapping was done correctly. */
        if (document.getId() == null) {
            document = null;
        }
    }
    return document;
}

[monstermichl]

Alright, the behaviour in the previous comment only worked, because the ID field which we use internally (_id) had a different column name for each document type. Now that I changed it to internalId for each document type, the trick with checking the ID for null doesn't work anymore. The repository basically returns any object that it finds with the provided ID and maps it to whatever class is provided.

[jesse-gallagher]

That last bit of behavior - taking any object with the ID and mapping it to the class in the repository - is intended. I've pondered the notion of restricting it to documents where the Form item maps, but that would cut off some potentially-useful uses where someone would intentionally open a document with a different entity name. Since Domino doesn't separate documents within the same NSF, I decided it's best to leave the behavior loose even though it may not always be desired.

If you do other queries, like a method such as Optional<Artist> findByName(String name), that will restrict to documents where Form=Artist, since internally it'll include that in the DQL search.

All this said, you mentioned the ID field being _id. That's the name that the driver uses internally as a placeholder for the document UNID, so it's actually technically not readable or writable as a note item via this. That makes me think that I should modify that and other "special" names to be more unique than they are, since _id is a legal item name. That will have to happen in 3.x, since it'll technically be a breaking change due to the way Java handles string constants.

[monstermichl]

Alright, thanks for the explanation, I can see your point. I'm just wondering if this behavior would be more expected than the behavior that it actually takes the form name into account on findById. As this function is on the DominoRepository and the Repository is bound to a type anyways, wouldn't it make more sense to add a findByIdLoose (or similar) method to DominoRepository? Just bringing in some ideas.

The _id field shouldn't be a problem, it's private anyway.

@Entity("Customer")
public class Customer implements IDominoDocumentEntity {

    @Id
    private String _uid;

    @Column("customerId")
    private String _id;

I just wanted to make my point clear that on Customer the _id fileld was mapped to "customerId" while the Artist _id field was mapped to "artistId" and therefore I could check the _id field in case the mapping didn't work properly as they both pointed to different field names in the database. So I don't think this should be a problem on your side.

One thing that would be interesting to me would be to derive entities from other entitiy classes. As you can see in my example I have the classes Artist and Customer where both of them implement the _uid and the _id field and their corresponding getters/setters. I would like to put these into a base class. However, when I do so, the Annotations don't work anymore (most probably because the base class is not marked as an Entity).

[jesse-gallagher]

Ah, gotcha, that's good to know. I think it'll still be best for the driver to change away from using _id internally, since it could be a field for SOME app, but not the underlying problem here.

As for subclassing, I THINK that's something that's improved in newer versions of the upstream JNoSQL and Jakarta Data projects. I'll check on that when I make the big switchover when Domino 14 is released, and it's possible that it'll just work better "for free" at that point.

[jesse-gallagher]

I'm pondering the notion of having a variant of findById that lets you do form validation. I don't want to enforce that outright, since I'm wary of cutting off some of the "loosey goosey" techniques that actually go well with Domino, but it could make sense to have a version like findById(String id, boolean checkForm) that wouldn't return the document if the form doesn't match.

[monstermichl]

At least it would be great to have the option of subclassing as from my point of view it would make a lot of sense since some forms are very similar or have some properties in common.

Yeah sure, I see your point. At the moment I'm using a workaround by using a separate ID field (pinnedId) which can then be looked for with findByPinnedId which incorporates the form name.