I concur with what Martin said.
/Patrik

On Sun, Mar 30, 2014 at 11:21 PM, Raman Gupta <[email protected]> wrote:

> I would stick with a "version" attribute on the events, which then gives
> you the flexibility to use promotion or explicit version handling on a
> case-by-case basis.
>
> Maybe one way to handle event version promotion with akka-persistence
> would be to implement a kind of "recovery roll-forward" as a variation of
> the "Recovery Status" pattern described at
> http://doc.akka.io/docs/akka/snapshot/scala/persistence.html#Recovery_status
> .
>
> As the processor recovers and receives each v1 event, it promotes it to a
> v2 event and resends it to itself (is this ok or will this result in a
> potentially huge mailbox?).
>
> The v1 event is then marked as deleted. As described in the "recovery
> status" pattern, any new v2 events received during recovery need to be
> stashed after recovery (and before "FIRST") to maintain the ordering.
> However, the processor should differentiate between v2 events that were
> promoted and thus should not be stashed vs new v2 events that should be
> stashed. I think one possibility is to create a "fromVersion" event
> attribute, which can then be used by the processor to skip stashing if
> fromVersion < currentVersion.
>
> Related: 1) Snapshots should be turned off for the promotion
> (SnapshotSelectionCriteria.None) to ensure the pre-snapshot v1 events are
> promoted as well. 2) Views should probably use the fromVersion attribute
> intelligently as well.
>
> Thoughts?
>
> Regards,
> Raman
>
> On Sunday, March 30, 2014 9:16:42 AM UTC-4, rrodseth wrote:
>
>> Thanks, Martin and Roger. Would anyone else care to weigh in on this?
>> Strategies for migration?
>>
>> DDD/ES with Akka persistence is just something I'm reading about at this
>> point (and dying to use). It does feel like a game-changer, but this issue
>> of data model migration is a big unknown for me.
>>
>> Thanks!
>>
>>
>> On Thu, Feb 27, 2014 at 1:05 AM, Roger Alsing <[email protected]> wrote:
>>
>>> There is a quite nice approach that Rickard Öberg uses for Qi4J.
>>> He uses _two_ versions for each message.
>>> "old" and "new"
>>> old events needs to be able to be promoted to new events.
>>> so each time you deploy, you promote old messages to new messages, and
>>> the system will run with only the new version.
>>> this way, you never ever have to have code for more than two versions at
>>> any given time.
>>>
>>> Not sure how this plays with Akka persistence, but I Think its a nice
>>> approach since you dont have to deal with 10 year old versions in long
>>> lived systems.
>>> (Then again, people may object to the fact that you need to tansform old
>>> to new and that it might alter the history.. but thats a different story :)
>>> )
>>>
>>>
>>> Den onsdagen den 26:e februari 2014 kl. 18:53:49 UTC+1 skrev rrodseth:
>>>
>>>> Now that we're getting excited about using akka persistence for
>>>> event-sourced DDD applications, can anyone provide any insights or
>>>> resources about handling versioning? Anything specific to akka persistence?
>>>> For example I have a book (produced by Microsoft) that talks about
>>>> mapping/filtering events in the infrastructure before they reach the
>>>> domain. How would we do that with akka persistence?
>>>>
>>>> Thanks in advance.
>>>>
>>>  --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>> >>>>>>>>>> Search the archives: https://groups.google.com/
>>> group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To post to this group, send email to [email protected].
>>>
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>  --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Typesafe <http://typesafe.com/> -  Reactive apps on the JVM
Twitter: @patriknw
JOIN US. REGISTER TODAY! <http://www.scaladays.org/>
Scala <http://www.scaladays.org/>
Days <http://www.scaladays.org/>
June 16th-18th, <http://www.scaladays.org/>
Berlin <http://www.scaladays.org/>

-- 
>>>>>>>>>>      Read the docs: http://akka.io/docs/
>>>>>>>>>>      Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>      Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to