BeforeRecordCreateListener does not update index #807

Activity

1. lvca commented on Jan 26, 2023

   

   lvca

   on Jan 26, 2023

   Member

   More actions

   @vic0824 I don't see the test case.
2. lvca commented on Jan 26, 2023

   

   lvca

   on Jan 26, 2023

   Member

   More actions

   Does your callback return true with no exceptions?
3. vic0824 commented on Jan 26, 2023

   

   vic0824

   on Jan 26, 2023

   Author

   More actions

   Sorry, forgot the attachment, I have now edited my post and added testBeforeRecordCreateListenerWithIndex.zip.
   To answer your question: yes, I return true always, because what could possibly go wrong? If the select for some reason does not return any record, the variable will be set to 0, otherwise it will be incremented.
   This is the listener:

   final BeforeRecordCreateListener autoIncrementListener = record -> {
   	int maxId = database.query("SQL", "select max(id) from Order").nextIfAvailable().getProperty("max(id)", 0);
   	record.asDocument().modify().set("id", maxId + 1);
   	return true;
   };
   

   maybe I'm not using the correct method to update the record? I could not find any other way and this seems to work, in that it does automatically increment the id at every insert, it just does not seem to update the index, or rather, the index is updated with null, which subsequently creates a duplicate key situation, because the id is what ensures that the index is unique.
4. lvca commented on Jan 26, 2023

   

   lvca

   on Jan 26, 2023

   Member

   More actions

   I've created this test case from your listener and it passes.

   @Test
   public void testBeforeCreateEmulateIncrement() {
     final BeforeRecordCreateListener listener = record -> {
       int maxId = database.query("SQL", "select max(counter) from `IndexedVertex`").nextIfAvailable().getProperty("max(counter)", 0);
       record.asVertex().modify().set("counter", maxId + 1);
       return true;
     };
   
     database.getEvents().registerListener(listener);
     try {
       database.getSchema().createVertexType("IndexedVertex").createProperty("counter", Type.INTEGER).createIndex(Schema.INDEX_TYPE.LSM_TREE, true);
   
       database.transaction(() -> {
         final MutableVertex v1 = database.newVertex("IndexedVertex").set("id", "test");
         Assertions.assertFalse(v1.has("counter"));
         v1.save();
         Assertions.assertEquals(1, v1.get("counter"));
         Assertions.assertEquals(1, database.countType("IndexedVertex", true));
   
         // SHOULD OVERWRITE THIS
         database.newVertex("IndexedVertex").set("id", "test2").set("counter", 1).save();
   
         final MutableVertex v2 = database.newVertex("IndexedVertex").set("id", "test3");
         Assertions.assertFalse(v2.has("counter"));
         v2.save();
         Assertions.assertEquals(3, v2.get("counter"));
         Assertions.assertEquals(3, database.countType("IndexedVertex", true));
   
         Assertions.assertEquals("test2", database.query("SQL", "select from `IndexedVertex` where counter= 2").nextIfAvailable().getProperty("id"));
       });
   
     } finally {
       database.getEvents().unregisterListener(listener);
     }
   }

   How your case is different from this one?
5. lvca

   self-assigned this

   on Jan 26, 2023
6. lvca

   added

   unable to reproduce

   on Jan 26, 2023
7. lvca

   added this to the 23.1.2 milestone on Jan 26, 2023
8. vic0824 commented on Jan 27, 2023

   

   vic0824

   on Jan 27, 2023

   Author

   More actions

   I have edited my post and uploaded the test case, but it's not there, so I upload it here in this post.
   The differences between your test case and mine are:

   • I have an index which includes the property that is set by the listener
   • I register the listener on the type, you register it on the database

   testBeforeRecordCreateListenerWithIndex.zip
9. vic0824 commented on Jan 27, 2023

   

   vic0824

   on Jan 27, 2023

   Author

   More actions

   I have modified my test case to register the listener on the database, instead of the type, but the result is the same.
   So the issue seems to be caused by the fact that the property set by the listener is included in an index.
   If you remove that property from the index, it works.
10. vic0824 commented on Jan 28, 2023

    

    vic0824

    on Jan 28, 2023

    Author

    More actions

    I have done some more investigations, and I have found that the problem is not related to the listener, but it is a general problem with the execution of an UPDATE statement when there is a composite unique index on a pair of STRING and INTEGER properties.
    I have opened issue #812.
11. lvca commented on Jan 28, 2023

    

    lvca

    on Jan 28, 2023

    Member

    More actions

    Thanks so much for providing the test case to reproduce it. I've followed up on #812. Closing this as not reproducible.
12. lvca

    closed this as completedon Jan 28, 2023
13. lvca

    added

    invalidThis doesn't seem rightThis doesn't seem right

    on Jan 28, 2023
14. mergify

    added a commit that references this issue on Oct 11, 2025

    chore(studio-deps-dev)(deps-dev): bump semver from 7.7.2 to 7.7.3 in …

    ...

    aab7637
15. tae898

    added a commit that references this issue on Jun 28, 2026

    chore(studio-deps-dev)(deps-dev): bump semver from 7.7.2 to 7.7.3 in …

    ...

    0a886fe