I've started checking upgrade requirements from V1.6 to V3.03.

Not sure if I'm missing something obvious but I can't find any reference to how to interact with relational data in V3.0.3.

In v1.6 this would typically be something like:

var promise = Kinvey.DataStore.get('events', 'event-id', { relations : { location: 'locations' }, success : function(response) { ... }});

Can't seem to find anything similar in docs or code in 3.0.3. How should on interact with KinveyRef's in 3.0.3?

Interesting Question - i have the same! :)


Can't understand why dropping the backbone Stuff to create some "own" ... ? :/

Hi Willem,

Can you tell me more about your use case? Would it be possible for you to denormalize your data?

Regards,

Wani

Kinvey Support

I guess the use-case is, simple relational data? (for me it is)

Like a collection containing books with a reference to the author. Isn't that supported anymore?

Best, Nico

Hi Nico and Willem,

We have deprecated KinveyRefs. Instead, we encourage developers to denormalize their data. Our scale makes it so it doesn't matter how many rows or columns you store in each collection.

The idea behind this is: What data does each screen in the mobile app need? Then store all that data in a single collection so you don't need to join tables. This is not always possible and in that case you can duplicate data across collections. Business Logic (BL - http://devcenter.kinvey.com/angular-v3.0/reference/business-logic/reference.html) makes this easy. The idea here is you will have fast reads and slow writes. Most API calls are reads so this should be OK.

In this case you could include the author object as a field in the collection that refers to it. When an author is updated in the postSave you can have BL update the duplicated author objects.

When foreign ids are needed you can use them using "contains" or "$in" as Mongo calls it: https://docs.mongodb.com/manual/reference/operator/query/in/ The SDK should abstract querying so you don't have to work too much about Mongo syntax.

Regards,

Wani

Kinvey Support

Hmm, so if there a collection with - let's assume - 100 Models with a connection to a user for example. 

The "new" way is, if the user changed his first_name, to update all 100 Entrys?


Best, Nico

Hi Nico,

Yes, that would be one way to do it. This will mean that you will have faster reads and slower writes.

Your schema design has to be based on what data (for the author) needs to be fetched together with the books information e.g. first_name or full_name yes, date_of_birth probably not. This way, your application UI design will influence your schema as well.

We are still discussing if relational data or kinveyRefs can be supported with v3 in some other (maybe limited) way. I will update you if we decide to make any such changes.

Sorry about the delayed update.

Regards,

Wani

#no offense but doesn't that lead into a direction to faster upgrade my payment plan at kinvey? Cause of the execution times for the business logic?

Cause, as you say, updating XXX Entitys (writing) could take a long time, doesn't it?

Best, Nico

Hi Nico/Wani,

WRT to our app and way forward - we only had a handful of scenarios where KinveyRefs and library based relations resolution where used. We've goten rid of this as we make much more extensiv use of Kinvey BL to enhance objects, for retrievals in post fetch, for writes in pre save and for dependant writes in post save - two things to take note here:

1. The 2 second BL timeout does come to play at times so this is limited

2. On writes its important to manage this properly e.g. not make use of relational writes - when writing main object ensure the related property is deleted before submitting and when writing a related object make sure the enhanced object is refreshed e.g. opposite of denormalization and mimicing the relational functionality in old library - Nico in your scenario

- Books collection has a ref property to ID in author collection

- On Books retrieval - postFetch method

   - Loop through selected books array and get all unique values for author ref property in resulting books selection set

   - Get all authors for this via a _id : { $in: query

   - Loop through resulting author set and build a unique object map of it

   - Loop through book array replacing ref for author with the object from the author set - this results to an identical response to a relations lookup against books collection that you would typically have done on previous version of library

- On writing updates to books either keep the author object that has been exploded in postFetch as is or replace with simple ID ref (as it was before it was exploded first time) - we use option 2 to keep data in books collection clean  - denormalization would dictate that you would keep the object there, we don't as we don't want negative write implication as per above discussion

- On writing authors refresh books so that new data is available in related property - you would have to do this either way whether using relational resolution in the old library or above method 

As long as you can effectively manage he 2 second BL timeout some simple BL can give you what relational data gives you and then some, e.g. we have a lot of conditional enhancement on postFetches that you could never do with pure KinveyRefs.

Kind regards,

Willem

Thanks for your answer! A bit more clear now.


But a second question:
For the Titanium SDK - why moving away from the backbone implementation? Alloy use it and with the new Kinvey SDK, we need to fill our Collections manually instead of just calling "fetch". Including some nice functions/paramaters backbone is giving us.

Did i miss something?

Best, Nico