Updating key for PState

[jacob franco]

I have a system where we are working with a Series object and its fields can be edited. We have two PStates we need to edit:

Originally, I had my implementation to edit the seriesIdToSeries PState and it worked as expected.  However, I was wondering why my changes did not seem to persist sometimes, and it was because we needed to edit both PStates.  So I got something like this:

We know that the implementation for the $$seriesIdToSeries part was working.  I added the .localSelect to get the un-edited Series object from $$seriesIdToSeries so we could extract the old start time.  That way, we could utilize that to more efficiently find the series with the proper id, since we had that in scope already (since the id doesn't change). 

I haven't tested this yet, so I don't even know if this approach works yet, but I do know that this is going to lead to a problem, because the start time can be edited, and that's our key.  So while we update the Series object itself, the old start time will still be the key. 

So I'm kind of confused on what I should do here so that we can change the key from the old start time to the new start time. 

Any help or insight is appreciated!

[Nathan Marz]

Usually for cases like this, it's easier to have $$startTimeToSeries instead be $$startTimetoSeriesId. That requires an extra lookup to resolve time -> Series object, but that's usually fine. If it's not and you need to absolutely minimize the queries, the way you're storing it is fine and just requires more logic in the topology.

It seems that when the start time is updated, you'll need to remove the old value from $$startTimeToSeries along with adding the new one. Otherwise, if you decide to continue with Series objects being stored in both PStates, then you'll need to update both location each time. Using the Series ID to find the old start time is the way to do it so that you can remove the one associated with the old start time.

Note that everything in your topology code is atomic, so there's no way a query can see those two PStates out of sync.

--
You received this message because you are subscribed to the Google Groups "rama-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rama-user+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/rama-user/7378ad04-8c29-4401-a31c-6b959ff944bfn%40googlegroups.com.

[jacob franco]

Okay I want to make sure I'm thinking about this in the right way.

So we extract the edits, then get the old series, so we can get the old start date.  We then apply the edits to both PStates.  Then, after both of those are completed, we check to see if the start time was edited.  If it was, we take the updated series object only with the wrong key and copy it.  We then delete the mapping at the old key.  We then get the new start date from the updated series, and then use that start date as the new key and make the value the updated series object.  Should this work as I expect it to?

I'm slightly concerned about the CONTAINS expression because I think I took a shortcut there that I can't really do.  Like I don't think it will interpret it in the way that I want it to, in either that it always returns false because it's just not a valid comparison or it returns true more often than it should (i.e. if "start" appears in like a field value or something).  Should I make a comparison to *fieldName instead, or maybe a comparison to the keys of edits ?

[Nathan Marz]

I'm not sure what the type of "*edits" is or how you populate it, so I don't know whether your Ops.CONTAINS expression on it is valid.

A simpler flow would be:

- localSelect to get the current Series object

- apply edit to that object to get the new Series object

- localTransform on $$startTimeToSeries

- localTransform on $$seriesIdToSeries

- if start date is changed, another localTransform on $$startTimeToSeries to remove it

Your current code seems to have more PState operations than necessary.

To view this discussion visit https://groups.google.com/d/msgid/rama-user/100cfbf5-6ad3-463a-b8e3-4530c68ce96dn%40googlegroups.com.

[jacob franco]

Alright I have some more questions.  So for starters my intuition that Ops.CONTAINS was going to be invalid was correct.   *edits is a list of field name-value updates, represented by a Thrift union.  I believe that I updated my logic to work with that more accurately. 

However, I'm confused about the flow you described.  How can I just directly edit the Series object like that ? I was under the impression I needed to do it via a localTransform on the PState. 

Here's what I'm working with now:

So we do the following:
1) Extract the list of edits to be made
2) We get the current series by id, and extract the current start time
3) We iterate over the edits list and get the field name and field value. 
4) We look at the field name and see if it was the start field that was edited and assign *startChanged a boolean value
5) We edit the given field in both PStates
6) If we're currently editing the start field, we copy the updated series, delete the old entry at the old start time, get the new start time, and apply the transformation for the new start time

So I'm wondering is the logic I currently have making sense? Is there a fundamental misunderstanding of Rama processes or general programming in here? I see some room for optimization, but I'm having trouble forming a concept about it. 

Thanks for the help Nathan, most appreciated. 

[Nathan Marz]

The Series object is just a Java object. So you can fetch it from the PState, modify it, and then write it to the two PStates. The transforms would be of form `.localTransform(Path.key(...).termVal("*series"))

The simplest thing to do is just make a lambda or helper function to take in the current Series object and the list of edits, and apply those edits to that Series object. Thrift objects are mutable, so you would then take that Series object and write it to both PStates according to its start time. You can capture the start time currently in the object before applying the edits, and then if that differs from its new start time, remove the entry under the old start time. So you would have two localTransform calls to update the two PStates in every case, plus an additional localTransform to remove the old one when the start time changes.

To view this discussion visit https://groups.google.com/d/msgid/rama-user/71d0607d-de9d-40ea-b01b-4095e4799cean%40googlegroups.com.