-
-
Notifications
You must be signed in to change notification settings - Fork 206
feat: Add saveEventually
and deleteEventually
in ParseObject
#911
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
I will reformat the title to use the proper commit message syntax. |
saveEventually
and deleteEventually
in ParseObject
saveEventually
and deleteEventually
in ParseObject
Thanks for opening this pull request! |
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #911 +/- ##
==========================================
+ Coverage 39.61% 40.60% +0.98%
==========================================
Files 60 60
Lines 3337 3401 +64
==========================================
+ Hits 1322 1381 +59
- Misses 2015 2020 +5
☔ View full report in Codecov by Sentry. |
Changed to draft |
saveEventually
and deleteEventually
in ParseObject
saveEventually
and deleteEventually
in ParseObject
@mtrezza @Nidal-Bakir |
I suggest looking at what other SDKs do and doing the same. There is the concept of a Queue so the objects get saved in order. Do other SDKs save the unsaved Objects even when the app is closed(destroyed) using native services (android and iOS) when the connection is restored for example? |
I think the queue issue happens in dio or Http and we don't need to create this queue. According to the ios documentation
Based on what I understand, the internal structure of Android is implemented with this concept. If possible, take a look at the Android structure. The concept that I didn't understand was where to double check and send the saved it objects? I wrote the codes of this section in the |
refactor: Add `CONTRIBUTING.md`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall everything is good.
I have some thoughts:
- What will happen if the current user logs out?
- should we clear the cache? or could you give the end user the option to decide what should happen?
- should we give the end user control over the cached objects that need to be saved/deleted?
@@ -677,4 +722,89 @@ class ParseObject extends ParseBase implements ParseCloneable { | |||
return this; | |||
} | |||
} | |||
|
|||
static Future<ParseResponse?> submitEventually( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
who should call this faction the end-user or the SDK itself when initialized?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly my problem is here, I don't know where this function should be used, whether the user should call or the SDK and where in the SDK
At the moment, the caches are not deleted, but I think a function should be written to delete the cache Regarding the second question, I did not see anything in other SDKs. Do you have any suggestions for this? What control do you mean? |
Got it.
I mean what if the user wants to clear the currently cached objects for saving/deleting and start over? Or in general, should we expose the current cache state so the end user can alter it? If yes we should consider a saving mechanism like functions to be invoked. for example:
something like that |
I don't think this is necessary. I haven't seen anything about this in other SDKs. Do you have a reason why it needs to be added? |
No, I'm just wounding if we need to give the end user finer control over the eventual save in general. If the other SDKs do not do that we are good. So currently, we need to discuss how the |
What's missing in this PR to get it merged? |
The code is finished, the tests must be written |
The error related to |
Done 😃 |
Note for review: The Flutter test is failing, hence we need to merge #969 first before merging this PR. |
saveEventually
and deleteEventually
in ParseObject
saveEventually
and deleteEventually
in ParseObject
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you check whether I've resolved the conflicts correctly? Then I believe this can be merged.
I checked, and there was no problem. |
Pull Request
Issue
Closes: #149 and #194
Approach
In this feature, Functions
saveEventually
anddeleteEventually
inParseObject
were added---> in
saveEventually
At first, normal
save
command is entered in parseObject, if aNetworkError
is encountered, this object is saved in a list with a key with the help of ParseCoreData.In our collection, we have a list of objects in
ParseCoreData
that are inNetworkError
.---> in
deleteEventually
At first, normal
delete
command is entered in parseObject, if aNetworkError
is encountered, this object is saved in a list with a key with the help of ParseCoreData.In our collection, we have a list of objects in
ParseCoreData
that are inNetworkError
.---> in
await ParseObject.submitEventually()
With the help of the function
await ParseObject.submitEventually()
(which is debatable how to use it) we checks the error objcetsIn this function, we first get the error parseObjects from
ParseCoreData
, then we send this list to_saveChildren
. In this function, these objects are sent to the server in the form of chunks, and finally, we empty theParseCoreData
list.In the following, we also take the list of
parseObjects
that must be deleted fromParseCoreData
and try to delete them, and then we delete the successfully deleted parseObjects from theParseCoreData
list.@parse-community/flutter-sdk-review
Please check these two functions thoroughly and give suggestions, this PR needs discussion.
and please check the algorithm, is this method good?
Tasks