@corneil did you create the right views/n1ql indexes when searching by user id? only the findById is key/value since otherwise we need a secondary index to look up the document.
Query derived for the method findOneByUserId would require N1ql indexes. Are you able to retrieve the other contents of UserInfo where only Id is null?
If you look at the little sample project I linked to there are tests in
I haven’t tried a fineOne using an id.
testFindAll and testFind pass the tests.
testBasicSave fails with id null after save
id has value when using findOneByUserId
testSaveAndGroupUser print the following:
Basically, it means that id is null after save, Object of classes annotated
as @Document are embedded and not ‘linked’
Hi @corneil, is it confirmed that it’s still an issue of spring-data-couchbase that save(…) method returns entity with null id
(@Id with @GeneratedValue(strategy = GenerationStrategy.UNIQUE))
cause I’m facing the same issue. To work around I have to explicitly set id before saving
The unique id was indeed used for saving the document, however there was a bug in updating the id on the saved entity returned. This is now fixed in current master, it will be available in the next release.
The problem is resolved for the top level entity but it looks like it still exists for the nested elements.
e.g. if the entity is like (in kotlin) data class TestEntity(@IdAttribute id: String?, name: String?, gender: String?, children: List<TestEntity>), then,
id is being read properly for the top level object
id for all the children are returned with their respective ids populated as null
the remaining attributes - name, gender, are populated correctly for both top level object and all the children
Note:
in my case, I am using GeneratedValue(strategy = GenerationStrategy.USE_ATTRIBUTES with the other appropriate settings; so the document key in the database should be the configured prefix + id
if we remove @IdAttribute annotation from id, then the above problem is solved. However, of course, as expected, the document key (in the database) is generated with only the prefix value, i.e. the id is not appended to the prefix value in the document key.