I have a managed object lets say products and I have another object that getting the data from another server and is already stored as managed object. There's nothing you in terms of the JSON data you get from the server that you can relate the two objects together. The only way is to do it manually before you get send the request. Is there a way to create a relationship that can do that using Restkit?
If you have the unique identifier of the source object in the request path or somewhere in the response body then you can use it in the mapping and perform a foreign key mapping to connect a relationship between the source and response objects.
If the identity is in the request path then you need to use RKRoute to prepare the request and #metadata.routing.parameters in your mapping to extract the identity. If it's in the response body then the standard mapping approach applies.
Once you have it, you map it into a temporary attribute on your destination object.
Once you have that you can perform your foreign key mapping.
Related
I am trying to understand a Python package called Instaloader and how many requests are actually being made to the Instagram server. With Instaloader, one can create a Profile instance from a given username with the following snippet of code:
loader = Instaloader()
loader.load_session_from_file(login_name)
profile = Profile.from_username(loader.context, target_profile)
Q1. Am I correct in assuming the last line makes a single request to the Instagram server? Am I also correct in assuming I am creating a data object (and not a reference) that is being stored in the "profile" variable?
profile_full_name = profile.full_name
Q2. Am I correct in assuming this does not make a request to the server, but retrieves a parameter from the data object in the profile variable?
followers = profile.get_followers()
Q3. Am I correct in assuming this makes another request to the server and stores the data object in the "followers" variable? The documentation says the return type is "NodeIterator[Profile]". Does this mean I am storing the data object for each profile from the target's followers? Or am I making a reference to each of those profiles?
Q4. If I am storing the data object for each profile, does that mean extracting information from the data object for these profiles will NOT make additional requests to the server? (Because I already have it stored in the "followers" variable?)
Or does it operate as a reference and thus: each moment I extract additional parameters from a follower profile, it will require an additional request to the server?
These answers were provided to me elsewhere:
A1. Yes, Profile.from_username() does make a single request to Instagram, which contains most of the profile metadata, and returns a Profile instance with that data included.
A2. Yes, full_name is already included in the data structure returned by Profile.from_username() and accessing it will in this case not trigger any further requests.
A3 & A4. get_followers() makes one request to the server and returns a NodeIterator. Some of the followers are already included with a thin data structure, containing only basic information. Iterating this iterator or accessing the items it yields will trigger further requests as required.
I am using Azure Table Storage Rest Api to Update the entity.
If the entity has 5 columns(col1,col2,col3,col4,col5) and I am making a PUT request body something like this.
{"col1":"value"}
The rest of the columns value is set to NULL.
Is there a way to avoid it?
The reason you're seeing this behavior is because you're performing Update Entity operation which will replaces an entire entity.
If you're only interested in changing just one attribute (property), you need to use Merge Entity operation which updates an existing entity by updating the entity's properties. It does not replace the existing entity.
Simply changing your HTTP Request method to MERGE from PUT should do the trick.
NSIncrementalStore has a required method "obtainPermanentIDsForObjects".
To get the ID's I have to create new row's in the database. Then to save the data in
executeRequest:withContext:error:, I have to hit the DB again.
Is there a reason why I shouldn't get new rowID's and save the data at the same time in obtainPermanentIDsForObjects?
The answer is probably not, if your entities have relationships.
To save a relationship, you need to uniquely identify the corresponding objects. Identifying an object requires your internal identifier which can be obtain via the permanent objectID (NSManagedObjectID).
But (some of) your objects won't have a permanent and internal ID yet because they haven't been handled yet in "obtainPermanentIDsForObjects"
In other words first you need to assign permanentID's (and thus also internalID's) before you can save references to them.
I have a repository class called FooRepository which has the ability to get various objects from a database.
I currently have one business object class called FooObject, which contains all the properties that I care about (Id, Name, CreatedDate, etc)... but my problem is that since ServiceStack only allows one DTO per route, I find myself unable to create more than one API method on my service to get back different types of data from my repository.
So, is it normal in ServiceStack to create a bunch of DTOs that simply return different types of data from the same repository? In ASP/MVC, this is rather easy because there's no route mapping clash going on, and I can simply create 'X' number of methods without the need to tie them to a specific DTO.
Thanks,
-Mario
Yes, each operation should have its own DTO. Keep in mind that the same DTO can be used for different HTTP methods(GET, PUT, POST, DELETE)
I'm using AFIncrementalStore to connect my iOS application to my REST API. When I load my initial view controller, I create an NSFetchRequest that loads the latest 100 Events (NSManagedObjects) into view. The problem is that each Event has a 1:1 relationship with a Group object, and as soon as the Event is loaded, the incremental store is asked to fill that Group object, which in my case triggers an individual request to the server for each of the 100 Events.
I can see a couple ways to solve this problem, such as not requesting Groups from the server if they are already saved locally, caching the network request, or not storing the relationship in the NSManagedObject. But ideally, the Group object could start out as a Fault and only request to be filled once one of its field is accessed, similar to what happens with one-to-many relationships. Unfortunately I can't find any documentation that says how to force a one-to-one relationship in core data to be lazy-loaded. Is it possible?
Maybe this is what you are looking for?
From AFIncrementalStore.h:
/**
Returns whether the client should fetch remote relationship values for a
particular managed object. This method is consulted when a managed object
faults on a particular relationship, and will call
`-requestWithMethod:pathForRelationship:forObjectWithID:withContext:` if `YES`.
#param relationship The relationship of the specifified managed object
#param objectID The object ID for the specified managed object.
#param context The managed object context for the managed object.
#return `YES` if an HTTP request should be made, otherwise `NO. */
- (BOOL)shouldFetchRemoteValuesForRelationship:(NSRelationshipDescription*)
relationship forObjectWithID:(NSManagedObjectID *)objectID
inManagedObjectContext:(NSManagedObjectContext *)context;
If so, you could set this with
- (BOOL)shouldFetchRemoteValuesForRelationship:(NSRelationshipDescription *)relationship forObjectWithID:(NSManagedObjectID *)objectID inManagedObjectContext:(NSManagedObjectContext *)context
{
return NO;
}
in your AFRESTClient <AFIncrementalStoreHTTPClient> subclass.
I've been struggling this as well. Looks like one-to-one relations will always be eager loaded. One way around this could be to declare it as a one-to-many relation so that it automatically does a lazy load instead. Then in your model class, you can have a method that returns the first one in the set.