In the design of a replacement application that I am working on it is
required that certain historical data be retained. Similar to the idea
embodied in "acts as versionable", the technique used in the existing
application employs the columns/fields of "date_effective_on" and
"date_superseded_after" which we are retaining in the replacement
application as this technique simplifies other parts of the code.
My question is: what is the suggested method/reSTful routing to
accommodate depreciating existing rows? There are two situations to
consider:
In the first case, the current row is replaced with a new row. In this
situation I conceive that the action is equivalent to http new and that
the controller action of posting a replacement row will check for the
existence of an active current row with the same natural key and, if one
exists, set the "date_superseded_after" on that row to the day before
the new row''s "date_effective_on", and then update both rows
in a
transaction.
In the second case, the current row is simply depreciated and no
replacement data is provided. The required action is simply to set the
"date_superseded_after" to some arbitrary date and update the record
in
place. Clearly an http put but what to call the method? It is not a
delete and it is conceptually different than a simple update of column
contents which, in general understanding, implies that the row itself
remains active.
I considered overloading the delete method to accomplish this but my
fear here is that end users, who are aware that historical data remains
available when depreciated, may inadvisedly extend this understanding of
delete into other areas of the application where a delete really does
mean destroy data.
So what to put in place of <?> in
"https://was.domain.tld/{collection}/{id}/<?>"? I am thinking
"expire"
but I am not sure that making up a new method name is in keeping with
the concept of ReST, thus my question.
Comments and suggestions are welcome.
--
Posted via http://www.ruby-forum.com/.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
I have a similar situation and found the answer to be in the model rather than the RESTful api. Specifically, I allow the user to create the record with the same ''natural key'' and then use an observer to determine if the natural key has already been used. If so, the observer deals with whatever is necessary to set the effectivity dates of the new object and the superceded one. "Expire" is really no different than update, allowing the user to set the expiration date. In our application, the user would be able to modify this along with the other attributes in their admin interface. You might conceive of ''expire'' like a very specialized ''edit'', though, and give it a RESTful url as you''re suggesting. I would restrict that method to presenting the very specific UI and letting the existing #update take care of persisting the change. On May 5, 12:46 pm, James Byrne <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> In the design of a replacement application that I am working on it is > required that certain historical data be retained. Similar to the idea > embodied in "acts as versionable", the technique used in the existing > application employs the columns/fields of "date_effective_on" and > "date_superseded_after" which we are retaining in the replacement > application as this technique simplifies other parts of the code. > > My question is: what is the suggested method/reSTful routing to > accommodate depreciating existing rows? There are two situations to > consider: > > In the first case, the current row is replaced with a new row. In this > situation I conceive that the action is equivalent to http new and that > the controller action of posting a replacement row will check for the > existence of an active current row with the same natural key and, if one > exists, set the "date_superseded_after" on that row to the day before > the new row''s "date_effective_on", and then update both rows in a > transaction. > > In the second case, the current row is simply depreciated and no > replacement data is provided. The required action is simply to set the > "date_superseded_after" to some arbitrary date and update the record in > place. Clearly an http put but what to call the method? It is not a > delete and it is conceptually different than a simple update of column > contents which, in general understanding, implies that the row itself > remains active. > > I considered overloading the delete method to accomplish this but my > fear here is that end users, who are aware that historical data remains > available when depreciated, may inadvisedly extend this understanding of > delete into other areas of the application where a delete really does > mean destroy data. > > So what to put in place of <?> in > "https://was.domain.tld/{collection}/{id}/<?>"? I am thinking "expire" > but I am not sure that making up a new method name is in keeping with > the concept of ReST, thus my question. > > Comments and suggestions are welcome. > -- > Posted viahttp://www.ruby-forum.com/.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
AndyV wrote:> I have a similar situation and found the answer to be in the model > rather than the RESTful api. Specifically, I allow the user to create > the record with the same ''natural key'' and then use an observer to > determine if the natural key has already been used. If so, the > observer deals with whatever is necessary to set the effectivity dates > of the new object and the superceded one.Thank you. I had not considered that route (pardon the pun). I will look into observers. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---