Nikita Prokopov

You’re relying on a fact that if length of a tuple is equal to the length of the index then we’re copying full tuple, keeping its layout. It is accidentally...

> When joining two tuples, the output tuple ordering must match the given :attrs This is correct to some extent: we don’t _need_ that, but it would be nice and...

> We could put a conditional that measures the number of attributes given. If l1 or l2 exceeds 8 No, this is too unreliable. CLJ/CLJS versions might change that parameter...

@wbrown-lg seems like an overkill to pull in a whole lib of fully implemented persistent data structure for such a small task. Can’t we build it using vectors for example?...

Right. I mean, it will have the same efficiency even, since array map lookups are same linear scans. Maybe we should rather use native arrays insted, might be even faster

Integer ids were needed because they’re much more performant than strings. In fact, it’s not that important that they are integers, rather, that they every id is comparable to any...

So pull isn’t working? Heh, I’m not sure whether it should or not... Entity, pull and similar APIs were not meant for pluggable storages. The query engine was, it (should)...

There might be problems with API compatibility. Right now both integers, strings and keywords have special meaning during transaction. If we allow them as ids, this would need to be...

I think any extra conditionals in such a hot place (index does LOTS of comparisons) would be harmful. But I see the connection you saw with #388, ideally, everything could...

Can you try with one of this jar or this patch (both are inside archive), whatever is easier? [Archive.zip](https://github.com/tonsky/datascript/files/5685698/Archive.zip)