Strings as keys instead of 64-bit integers?

[iljaiwas]

It seems that lidx uses 64-bit integers to uniquely identify originating objects. In my app design I'm using UUIDs to identify objects (128 bits).

Since LevelDB uses strings as keys, would it be feasible to switch from integers to keys as identifier?

[dinhvh]

There would be a performance hit by introducing it.
I can think about how to introduce strings as key.

[iljaiwas]

Thanks for considering my request, but it's probably not necessary.

Since I only need to support Mac & iOS, I'm probably better of re-implementing my own library on top of NSScanner/NSCharacterSet. All this ICU lib stuff is making my head spin. ;)

This way I can use strings as document keys. Please feel free to close this issue.

[dinhvh]

What was your issue with ICU?

[iljaiwas]

I don't have any issues with ICU in particular.

But it's another dependency I'd like to avoid, as (at least in my naive understanding) the same functionality is already contained in iOS/ OS X.

If I was the guys in our company to introduce a new full-text indexer to be used several projects, people would turn to me every time there's a problem with the source or the built-process. I'm just trying to minimize my future liabilities. ;)

[dinhvh]

The functionality I'm using to support i18n are not exposed through Foundation.
Using ICU directly is considered as private API.

[iljaiwas]

I was thinking about using CFStringTokenizer. https://developer.apple.com/librarY/mac/documentation/CoreFoundation/Reference/CFStringTokenizerRef/Reference/reference.html

Not sure how it differs from ICU, though, and what i18n features you are using. Do you have a minute to elaborate?

[dinhvh]

There's also probably an equivalent with transliteration that is needed for lidx.
I'll look into it. Thanks for the suggestion!