Allow non-numbers as entity ids

Bắt đầu bằng cách xem xét hàm entid và các giao thức IDB, ISearch và IIndexAccess được triển khai một phần trong adapter MapToDatascript được mô tả trong issue. Kiểm tra pull request được liên kết và phần thảo luận của issue trước đó trước khi quyết định liệu các ID thực thể linh hoạt có phù hợp với mô hình dữ liệu hay không; để hoàn tất, cần giải quyết thiết kế và kiểm thử mọi hệ quả trên tất cả các nguồn dữ liệu được hỗ trợ.

This has come up in a couple of issues before, both by developers being against it and for it. To wit: https://github.com/tonsky/datascript/pull/8#issue-32457706 https://github.com/tonsky/datascript/issues/56#issuecomment-73641241

Here's my case for a dynamic entity id type, rather than enforcing number?, as is done in the entid function.

I tried to integrate the high churn real-time data stream that my process receives and updates a in-memory map with. This map has something like the following, pretty common structure:

{ "key1"
  { "attrA" "foo", "attrB" "bar", ... }
 "key2"
  { "attrB" "foo", "attrX" "bar", ... }
}

It was easy enough to hook this map up to Datascript (Spossiba Tonsky, you ЯOCK! Datomic in contrast doesn't have published protocols...) by creating a MapToDatascript adapter, just implementing (partially, for the time being) IDB, ISearch, and IIndexAccess, and then query it like so, joining it with a real datascript DB:

(ds/q '[
    :find (pull $ ?e [*]) (pull $m ?attr-x [*])
    :in $ $m
    :where [$ ?e :attr-x ?attr-x]]
  @ds-db my-map-adapter)

Except, I had to tweak datascript's entid function - in fact simplifying it - in order to allow string eids, or just any type, for that matter.

Now I can of course create some number out of thin air and attach it to the entity to serve as the entity id, but that is another level of mapping that has to go on on every change of my data, which is thousands per second. What's worse, I now have another id that I need to keep consistent in the face of a machine going down and some failover machine taking over. That complicates things quite a bit.

So why not keep entity ids as flexible - for non-datascript data sources at least - as the datalog queries themselves, that don't care if your patterns are shaped [?e ?a ?v] or something completely different.

That way, integrating datascripts datalog engine with arbitrary data sources will be a lot easier, and depending on the case, more performant.

Is this a route you'd like to go in Datascript? Or is the datascript data model you want other sources to adhere to? In the former case, I'd have a more closed look at the sources and wrap this in a proper pull request, after checking and testing all the ramifications.