Concerns about using _id over _key in 0.10 about laravel-arangodb HOT 5 CLOSED

Thank you, for detailed response and explanation. It helped me a lot.

from laravel-arangodb.

I've just released 0.14 to make it easy to upgrade to it. It's the version with _key/id conversion. So it should be easy to upgrade to it from any version below 0.10 and skip the _id primaryKey from versions 0.10 - 0.13.

from laravel-arangodb.

Wow, thank you so much, there are so many cool features in releases in/above 0.10, so excited :)

from laravel-arangodb.

Hi, you're welcome.

id/_key vs _id

Back in the day I thought that _id would map nicely to 'id'; which was indeed easy and at first usage worked out nicely.
However it caused several follow up problems. A lot of third-party packages just assume an 'id' field and default to it or even hard code that in relationships and database queries.

So the mapping started to break down. To further compound on this issue it also required to override the default route key as
it's structure ({collection}/{_key}) isn't compatible with URL usage.

I've solved these problems in dev-next by mapping _key to 'id' on data retrieval and 'id' to _key in statement queries.
This is the most compatible solution I could come up with and since then most third-party packages can be used out of the box.

The most common incompatibilities are now the need to register locations in transactions and the lack of foreign keys in Arangodb, so you need to handle cascading deletes manually.

The model's primary key is now the regular 'id'. The only real problem with this is naming confusion when learning ArangoDB through this package, or coming from ArangoDB usage elsewhere. As _id and id are usually pronounced the same.

So, for regular eloquent usage I suggest to just default 'id' for relationships and queries.

You can use _id in relationships by setting them manually. So that allows you to use graphs and maintain eloquent functionality.
Note to set the collection type of the pivot to edge.

• Example of a relationship using _id
• Example of an edge migration

So this will be released in 1.0; until then you can check out dev-next; but of course the risk of breaking changes remains until 1.0 is released.

Performance

Both _key and _id are indexed by ArangoDB automatically. The difference is very minimal so you'll probably won't notice it in most use cases. I've just tried to find this information again but couldn't locate it. As I recall it's mentioned somewhere in the docs or one of the learner pdf's on their website.

For general usage I'd go for _key in regular joins and _id for graphs, polymorphic relationships (outside of eloquent) etc.
Basically use what makes sense from a data modelling perspective.

For third-party packages the first part of this reply already takes care of that by using _key under the hood..

Either way I wouldn't worry about it unless you go to the extreme use cases. ArangoDB is very fast.
If, in practice, you really do need every last drop of performance you can easily swap between _key and _id as the _key is part of the _id anyway. But doing that beforehand just for the sake of performance might just be a premature optimization.

If you have an extreme use-case you can run some performance tests on a large dataset under load.

Does this alleviate your concerns?

from laravel-arangodb.

Good luck over there! I hope you and your loved ones are and stay well!

from laravel-arangodb.