Allow to index binary / NSData properties

[johnburkey]

Strings are expensive and sometimes projects want to be able to index a hashable array object that has patterns in it and is sortable but isn't actually a string. It can be stored today as an NSData, but it would be great if it was indexable.

[mrackwitz]

I guess, you're speaking here of arrays of strings? We're tracking adding support for storing arrays of primitives (string, int, etc.) as RLMObject properties by issue #1120. Meanwhile you're right, you can use NSData as one way to workaround that. Another way would be to create a new model class in your schema. You can then define the string property as indexed.

class Person : Object {
   dynamic var name = ""
   let petNames = List<PetName>()
}

class PetName : Object {
   dynamic var name = ""

   override static func indexedProperties() -> [String] {
       return ["name"]
   }
}

[johnburkey]

I would like to use an array of bytes as and indexed property . It's like a hash except the key is not a string . Think of it as a piece of music with notes instead . A pattern from a set but notes instead of letters. String is too slow for my scenario. I'm already using Nsdata- but if I could have it be an indexed property it would be more useful .

John

On May 29, 2016, at 10:30 PM, Marius Rackwitz [email protected] wrote:

I guess, you're speaking here of arrays of strings? We're tracking adding support for storing arrays of primitives (string, int, etc.) as RLMObject properties by issue #1120. Meanwhile you're right, you can use NSData as one way to workaround that. Another way would be to create a new model class in your schema. You can then define the string property as indexed.

class Person : Object { dynamic var name = "" let petNames = List<PetName>() }

class PetName : Object { dynamic var name = ""

override static func indexedProperties() -> [String] { return ["name"] } } — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[mrackwitz]

If we would allow to index NSData properties, they would be indexed as a whole. Indexes can't support arbitrary binary data formats. So if you're searching for a specific note, it wouldn't help you at all. It would only help if you're instead searching for a specific set of notes. So is that what you're looking for?

[johnburkey]

Yeah. Sorry I miscommunicated - that's what I meant. Just like using a string index as you in effect said . There is a single value for each byte - as if the byte array were a uint8 backed string .

Thanks, John

On May 30, 2016, at 1:42 AM, Marius Rackwitz [email protected] wrote:

If we would allow to index NSData properties, they would be indexed as a whole. Indexes can't support arbitrary binary data formats. So if you're searching for a specific note, it wouldn't help you at all. It would only help if you're instead searching for a specific set of notes. So is that what you're looking for?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[johnburkey]

See what's cool about it is it means you can use a byte array backed Nsdata and have indexable enum arrays in effect . So not arbitrary - the enum gives u homogenous elements and a hash- and you can impose ordering if you like via a protocol.

Thanks, John

On May 30, 2016, at 9:34 PM, John Burkey [email protected] wrote:

Yeah. Sorry I miscommunicated - that's what I meant. Just like using a string index as you in effect said . There is a single value for each byte - as if the byte array were a uint8 backed string .

Thanks, John

On May 30, 2016, at 1:42 AM, Marius Rackwitz [email protected] wrote:

If we would allow to index NSData properties, they would be indexed as a whole. Indexes can't support arbitrary binary data formats. So if you're searching for a specific note, it wouldn't help you at all. It would only help if you're instead searching for a specific set of notes. So is that what you're looking for?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[mrackwitz]

Ok, I'll promote this to a feature request.

[johnburkey]

Thanks a lot!

John

On May 31, 2016, at 2:26 AM, Marius Rackwitz [email protected] wrote:

Ok, I'll promote this to a feature request.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[johnburkey]

Did you guys implement this? I have a super high performant case using byte arrays as a substitute for strings, and want to be able to index them. Each UInt8 can be handled just like a character- its like an enum.

• John

On May 29, 2016, at 10:30 PM, Marius Rackwitz [email protected] wrote:

I guess, you're speaking here of arrays of strings? We're tracking adding support for storing arrays of primitives (string, int, etc.) as RLMObject properties by issue #1120 https://github.com/realm/realm-cocoa/issues/1120. Meanwhile you're right, you can use NSData as one way to workaround that. Another way would be to create a new model class in your schema. You can then define the string property as indexed.

class Person : Object { dynamic var name = "" let petNames = List<PetName>() }

class PetName : Object { dynamic var name = ""

override static func indexedProperties() -> [String] { return ["name"] } } — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/realm/realm-cocoa/issues/3669#issuecomment-222414291, or mute the thread https://github.com/notifications/unsubscribe/ALpdvcyOZXaiK5kkyqjAkrVclaTHSaD3ks5qGnXygaJpZM4IpNgx.

[jpsim]

No we have not implemented this.

[johnburkey]

Alright, well think of it as a feature to do indexing on things that look just like strings, but aren’t actually multi-byte internationally safe unicode savvy things, but are still runs of values that occur in patterns just like characters do in words. Given how heavy weight string is becoming year after year, its a valuable feature to be able to have variable length piles of symbols / enumerated values in indexable fields in a database.

Thanks for the reply,

John

On Aug 19, 2016, at 12:09 PM, JP Simard [email protected] wrote:

No we have not implemented this.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/realm/realm-cocoa/issues/3669#issuecomment-241108260, or mute the thread https://github.com/notifications/unsubscribe-auth/ALpdvVtRMtBmDVv7xuuBIiStIYA6pYvXks5qhf96gaJpZM4IpNgx.

[jpsim]

Agreed, this is something we want to do, which is why we're tracking it here.

[johnburkey]

Sweet.

On Aug 19, 2016, at 1:07 PM, JP Simard [email protected] wrote:

Agreed, this is something we want to do, which is why we're tracking it here.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/realm/realm-cocoa/issues/3669#issuecomment-241121501, or mute the thread https://github.com/notifications/unsubscribe-auth/ALpdvUdBYJlFQEg8PMilsNRTrNDdi5yAks5qhgz2gaJpZM4IpNgx.