Key/Value vs JSON Documents

[AJ]

Hello,

Having written our own persistence layer similar to CoreData, I must say that some of the concepts in YapDatabase are very very cool! Kudos!

I'm trying to understand if YapDatabase is strict about Key/Value or does it handle JSON documents equally.

For example:
{
id = "123456789",
first = "Bob",
last = "Smith",
phones = [
{
label = "Work",
number = "123-122-1234",
type = "Cellular",
},
{
label = "Home",
number = "345-234-1234",
type = "Landline",
}
],
emails = [
{
label = "Work",
address = "b...@smith.org",
},
{
label = "Personal",
address = "bobs...@gmail.com",
},
],
}

Based on what I read, I assume the following:
1. We would store Bob in a collection called "People"
2. We serialized this *whole* JSON document so we do not put "phones" and "emails" into separate collections (phones and emails don't have unique IDs)

Are these valid assumptions?

If these assumptions are true, then can I do the following search *without* deserializing all 100000 objects in the collection?
"Find all people whose (label) 'Personal' email ends with (address) *.gmail.com and have 'Landline' phones"

I understand I have to use a View but how do I configure it?

--
Thanks!
AJ

[Joel Ekström]

Hi AJ!

There are two ways to store this data. Either you store the JSON object
directly (which would just be a string). There's no benefit to doing
this though. What you should do is create a Person class which has the
properties you need to store, and implement NSCoding on it. I'm sure
you've read up on this already. So to answer the first question, yes,
YapDatabase is strict about key/value. But the value can be any kind of
object, including a JSON string (but you should use
NSObject-representations instead).

Your assumption that you don't need to create separate collections is
correct. Every Person can go in the People collection. However, you
should be open to using collections in more flexible ways that you
traditionally use database tables. It takes some getting used to working
with key-value stores instead of relational databases. There could be
different collections for different groups of People, for example.

Anyway, back to your questions. The search you're looking to do really
seems more fit for a relational database. Are you sure that a key-value
store is a good choice for your use case? It's possible to do this in
YapDatabase using secondary indexes or perhaps full text search
(https://github.com/yapstudios/YapDatabase/wiki/Full-Text-Search).
However, in the end, a separate database table containing the properties
you want to be searchable will be created. If this works for your case,
then that's fine. The answer to your question is: no, all 100000 objects
will not need deserializing as long as you use some approach of
secondary index. If you want to be able to dynamically do any search for
any properties, then yes, it's likely that all objects will need
deserializing.

You don't necessarily need to use a view for this either. A view is one
kind of secondary index that's fit for some use cases. In particular,
it's great if you need a persistent/auto updating "fetch request" (as it
would be called in Core Data) that you want to show in your UI. For your
use case, I would assume that a plain secondary index or a full text
search is a better choice.

I hope this helps!

[Alykhan Jetha]

Thanks Joel!!
That was very helpful. Confirms some of the thinking I was doing after I posted the question.