Hi Ketil,
This is a decision that you can make according to your operational
requirements. I expect that it will typically be a mixture of the two since
switching to a new application version is quicker of no journal rewrite is
needed while long term you want to prune the old formats where possible to cap
the code ugliness and duplication.
Regards,
Roland
Sent from my iPhone
> On 21 Jan 2015, at 13:18, Ketil Johannessen <ketil.johanness...@gmail.com>
> wrote:
>
> Hi,
> Just to clarify: are you proposing an actor/application with the sole purpose
> of converting messages from old version to new version, or that the existing
> application with its actors should support multiple versions of the messages?
>
>> On Tuesday, January 20, 2015 at 1:08:38 PM UTC+1, rkuhn wrote:
>> Hi Ketil,
>>
>> during development you will commonly find and fix mistakes or add feature
>> which will require you to scrap all the (wrong) history, but that is fine
>> because nothing is really durable at that time. When you go to production
>> the use of persistence implies that you need to keep those data around—if
>> not then why would you persist them? So the only solution is to remain able
>> to read old data, which is most reliably implemented by never removing or
>> changing an old event type and only add new ones. While you can of course
>> convert all stored events on disk into a new format after a change, this
>> should not be a requirement for your program to run—it is more a maintenance
>> optimization.
>>
>> The best way to convert stored events is to replay them by an Actor that
>> will persist them in the new format, currently that would be a
>> PersistentView.
>>
>> Regards,
>>
>> Roland
>>
>>> 16 jan 2015 kl. 14:50 skrev Ketil Johannessen <ketil.joh...@gmail.com>:
>>>
>>> Hi!
>>>
>>> In my current project we are using akka-persistence with LevelDB. Our
>>> application is completely event sourced using akka-persistence, i.e there
>>> are no other mechanism for persisting business state in use.
>>>
>>> However, we have identified the need for being able to convert persisted
>>> messages, when deploying a new version of the application with changes
>>> effecting the persisted data structure (.ie new attributes, deleted
>>> attributes, changed datatypes). As of now, we must completely discard our
>>> business data every time we deploy a new version, in order to avoid
>>> exceptions when replay of persisted messages upon startup.
>>>
>>> I would believe that many other projects face the same problem, and believe
>>> that this could be solved with a general mechanism in akka persistence.
>>>
>>> I have done a poc on "daisy-chaining" persistence plugins, by creating my
>>> own plugin ("proxy-plugin") and have this plugin forward all messages to
>>> the actual persistence plugin (leveldb or cassandra). In addition we are
>>> using our own serializer, serializing all messages to json strings prior to
>>> persisting (to avoid class version issues).
>>>
>>> In my own proxy-plugin I can now register mapper classes (these
>>> implementing a common apply() trait, intercept messages and modify the
>>> persisted json-based messages from previous versions to the current
>>> deployed. This way we can keep our persisted business messages across
>>> versions of the message classes, without the need for discarding old data.
>>> The poc now is working ok for journals, but not yet for snapshots.
>>>
>>> There are also other cross-cutting concerns related to persistence where
>>> such a feature could be useful, for instance auditing
>>>
>>> Is this something that could be implemented in akka-persistence?
>>>
>>>
>>>
>>> --
>>> >>>>>>>>>> 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 akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> Dr. Roland Kuhn
>> Akka Tech Lead
>> Typesafe – Reactive apps on the JVM.
>> twitter: @rolandkuhn
>
> --
> >>>>>>>>>> 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 akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
--
>>>>>>>>>> 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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
