Akita: ID and guid() function documentation

[loicmarie]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[ ] Feature request
[x] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

• Some tutorials advice to use guid() function to create ID entities. This should appear in a dedicated section of the documentation.
• The uniqueness of the generated ID should be certified somewhere (as for the method used to generate it).
• It probably exceeds Akita perimeter, but it would be very useful to get some examples of interaction between Akita entity services and backend (such as MongoDB, Firestore or other) in order to properly use this Akita-specific ID at backend side.

In your different articles highlighting Akita's capabilities, you either use backend-specific ID (such as this, using Firestore ID and forgetting Akita ID). Or you simply don't talk about backend interaction (such as this, using Akita ID). What should we do ?

What is the motivation / use case for changing the behavior?

Since we cannot certify Akita ID uniqueness, all the implementations I found have horribles and useless IDs bindings strategies before executing CRUD operations from service to backend.
Can this ID be directly used as a document ID or primary key at backend side, in order to have only one entity ID type accross the entire app ?

Sorry for not following issue template, I didn't find it relevant for simple documentation requests.

[NetanelBasal]

The guid helper function generates a unique id. Actually, its primary purpose was to create an identifier for demos/playground environments quickly. I don't think there is any tutorial that was mentioning that it's safe to use as server-side id.

I understand that it's misleading and we'll update the docs.

Regarding the id. There is no such thing "Akita-specific ID". There are two cases:

1. You get the id from the server.
2. You generate an id for a new entity in the client, save it in the server, and use it as your primary id.

For example, if you're using Firebase, the entity's primary id is the document id.

There is something more specific you want to know?

[loicmarie]

Thank you for this precision, I was misunderstanding the guid() function purpose. I thought it was important in order to make relationships functions work, or to handle multi-backend IDs.

So there is no point to document guid(). But if I may, it would be great to see this two points in the doc :

Regarding the id. There is no such thing "Akita-specific ID". There are two cases:

1. You get the id from the server.
2. You generate an id for a new entity in the client, save it in the server, and use it as your primary id.

That's all I wanted to know, thank you for this (very) quick response.

[NetanelBasal]

No problem. You're welcome to join Akita's Gitter channel for any further questions you have.

[chriszrc]

There are two cases:
You get the id from the server.
You generate an id for a new entity in the client, save it in the server, and use it as your primary id.

Well, I think I have a third case. I'm generating ids for a new entity that's created on the client, but in this case, it's not saved to the server, but only a local download of the apps current state can be created (using snapshotManager.getStoresSnapshot()).

So using something like guid might be ok, but I'm guessing the user isn't really assured of not getting the same guid at some point. Also, because the entities aren't ever shared across users, using a regular autoincrement number would work just fine. Except when they come back to the app, and restore state. The autoincrement would have to be jumped ahead to the largest id value.

Has anything like this been tackled? Is there a recommendation in this scenario?

[NetanelBasal]

but only a local download of the apps current state can be created (using snapshotManager.getStoresSnapshot()).

@chriszrc I'm not sure I understand your use case. Can you provide more information, please?

[chriszrc]

Right, maybe this isn't exactly what the storesSnapshot was designed to do, but basically, for this app, the client doesn't want a backend. If we were using the akita todos app as an example, you could create todos, and then instead of saving to server, you download a json file of the current state. Then, with that file, even from another computer, you could upload the storeSnapshot json file and get the application right back to where you left it, todos and all.

Does that make sense?

[NetanelBasal]

You have two options:

1. Save in the store's root the last id, and then use it each time you add a new one.
2. Find the largest id number in the collection and use it as the starting poting.

[chriszrc]

Ok, thank you, just wanted to make sure I wasn't overlooking a built in solution. I also considered a third solution, using a modified guid approach that incorporated a timestamp, so there would never be a collision (since the ids aren't shared between users, the only collisions that would need to be avoided would be with the users own created ids)-