Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IDGeneration, saving & object_already_persistent #32

Open
niniemann opened this issue Jun 13, 2018 · 1 comment
Open

IDGeneration, saving & object_already_persistent #32

niniemann opened this issue Jun 13, 2018 · 1 comment
Assignees

Comments

@niniemann
Copy link
Collaborator

  • IncrementalIDGeneration needs to store "meta"-information: Prefix & highest assigned ID.
  • Currently, it only saves this information during its destructor
  • Problem: ctrl+x, crashes, etc. lead to inconsistent data, and when creating a new entity it is given an invalid id, resulting in an object_already_persistent exception when trying to save it
  • tried hotfix: Not only save it in the d'tor, but also every time it generated an id
  • Problem: transaction already in progress in this thread.
    • Load an entity
    • --> inside a transaction
    • create instance
    • generates Id (which is stupid in itself)
    • tries to save it
    • therefore, storage tries to open a new transaction
    • --> exception.
  • Possible fix:
    • storage: check if transaction already in progress
    • better: rework IDGeneration.

I'd like to change something fundamentally here. Original idea was to create the ID all the way down in the c'tor of DBObject so that every derived entity can already access and use it (especially usefull for creating a child-RDF-Entity / PropertyMap etc). By now I'm rather convinced that it would be better to split things up: Leave the "default c'tor" as simple as possible, without any ID-generation whatsoever, and add a second initialization step to set the id and update anything that relies on it.

@ctieben
Copy link
Contributor

ctieben commented Oct 2, 2018

Please also think about temporary entities.
See the simple solution in #53 which shall be solved by the architecture and not by flags.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants