Hello,
I have noticed some crashes with one of my apps. Probably I am doing something wrong but I noticed that a JSON file generated by serializing an Array of Objects was sometimes not usable to feed a Report.
If I am not wrong, it seems that the key "$$hashKey" is the reason when the object's number is duplicated.
For example :
The related project is attached. Am I true about the reason ? Do I have any solution to avoid the duplication about the object's prop ?
Many thanks
Project
Hello Samuel,
Yes; Report sources (Data), for example, don't support duplicates registries. Depend on the context, but, one possible way to avoid it is to add to the objects that you shown above another unique property, for example, an "ID" property which are unique per every object.
Please, go ahead if you have any further question around this or if need a bit more help. Take a look also at the recently added "TodoApp" sample, in which we must deal exactly with the same issue: save and restore (in the app's local storage) an array of objects.
Hello Samuel,
Looking at the "TodoApp" sample... well... I remember that I deal with "$$hashKey"... but what I do is to delete that key from the objects, before saved it to the local storage. So it's not exactly your case, Samuel. If I am not wrong, what you must to do is to assert that every object in your array are unique, and, this can be reached by adding another property to the object which are unique.
But reading twice your message... now I am not sure if what I imagine (the required unique objects) can be the problem in your specific case... or may you need to delete the "$$hashKey" property (then yes, look at the "TodoApp" app's Ready event. Or maybe we are talking about other thing... so please, go ahead and post here whatever you consider that can help... in order to try to help you too! :-)
Hello Samuel,
Thinking about... maybe your problem is exactly what I have in the "TodoApp" sample? That is,... what you want is to save a previously "reported data", and, at that time, the "$$hashKey" has been added behind the scene. So, when you try to load the saved data... a "$$haskey" property already exists in the objects, and therefore it's not possible to add a new one. So probably what you must to do is to delete the "$$haskey" property before save the object... and this is exactly what you can see in the "TodoApp" Ready event.
Hello David,
Thank you very much for your confirmation and having pointed me to the TodoApp example. I had missed the JavaScript code. Thanks for having studied and solved the case previously.
May I ask you, when you'll have some time and only for curiosity, the reason why we get that $$hashkey prop inserted ? If we reproduce the simple code like that one below, we don't see it.
Generates (without the reference to the object)
As a suggestion (not to have to deal with JavaScript), perhaps in the far future, could we have a new App Builder's function where we provide an Object input (like CopyVar) and can do actions on its Props (deleting, adding) and get another Object output ? (proposing that without knowing if it is feasible and how much time consuming it could be).
Again, David, thank you very much for the solution and confirmation you provided.
Hello Samuel,
Yes; the "$$hashkey" is added by AngularJS internally for their own purposes. The "problem" is that commonly we simply can ignore this property, except in case like what we are having here: we want to store the objects and therefore the objects are stored with their possible "$$hashkey" properties. Maybe this can be investigated in some way... but probably it's enough to "simply" iterate the objects before save it... in order to remove whatever properties that we don't want to store.
P.S. One thing to note: the "$$haskey" property are only added when the objects are part of a Report 's Data, for example, that is, commonly, we can have a list of objects or whatever structure... and nobody interfere in that objects: in this case the variable are assigned to a Report's Data, and then retrieved, and, here yes, the Report's processing added to their Data (our objects) the "$$hashkey", which may we need to remove, or not, depend on what we wanted.
Hello,
Me again to quickly report a fix based on David's provided solution :
just remember the capital K letter in $$hashKey (I did not noticed it on my HD+ laptop's screen) and feed the Object's related prop with a TimeStamp or any UID you can generate.
As David said, once that value is 100% unique, all is fine. Thanks again David for the quick fix.
You're welcome! The point is that you got what you wanted. :-)
Everybody can read the DecSoft support forum for learning purposes, however only DecSoft customers can post new threads. Purchase one or more licenses of some DecSoft products in order to give this and other benefits.