Hi Konrad, Thanks for your answer.
The development is always about tradeoff, and good tradeoff is always context sensitive. In my current context, performance is not as important as human readability. The following tradeoff is enough for me : - Metadata as binary in one field. - Payload as text in another field. I'm not a big fan of the "merge" of business data and persistent technical data, but I suppose it's designed for speed. You have your own tradeoff to choose from and I don't discuss them. However, I'm not very pleased by the solution "write your own journal plugin", it seems a big task relatively to the original problem which is "don't mix your data with mine". I also think that "don't mix technical data with business one" can be a reasonable requirement. Now that's said, I don't have much idea of a solution which do not impact speed and do not involve journal plugin api break (like separating the PersistentRepr data from the payload to discourage mixing). Le lundi 4 août 2014 12:32:24 UTC+2, Konrad Malawski a écrit : > > Hello Yann, > There is not “nulling” involved. The PersistentRepr acts as envelope for > your payload (your message), and adds some metadata to it (persistenceId > etc). > See details here: > https://github.com/akka/akka/blob/master/akka-persistence/src/main/scala/akka/persistence/Persistent.scala#L191 > > We serialise the entire PersistentRepr and persist it, inside it there > will be your payload, serialised with whatever you chose. > The goal here is to allow efficient serialisers, as well as to help out in > schema evolution (as Endre hinted with protobufs or something similar). > > If you want to have full control over serialisation, you could implement a > persistence-plugin, as then you’re the guy asked to persist the event. > In a schema-less db such as mongo you could explode the event json into a > document and add fields for persistentId etc… > Having that said I’m not a big fan of this aproach, and JSON is not the > best format for either speed or schema evolution (bigger reasons than human > readability IMO). > > > > On Fri, Jul 25, 2014 at 2:00 PM, Yann Le Moigne <[email protected] > <javascript:>> wrote: > >> Thanks for quick answer. >> >> So the journal plugin has to get and serialize the payload of >> PersistentRepr for readable format, then nullify it in PersistentRepr, then >> serialize PersistentRepr, and store both serialization result side by side ? >> >> The "nullify" part scary me, probably duplication is better. >> >> >> I have some concerns about durability of "core business data" which the >> journal is. I fear that data became unreadable without the help of akka >> because "business data" if wrapped in binary technical data. >> Also for debugging business state, being able to have the journal in a >> readable format is a major advantage. >> >> >> Le vendredi 25 juillet 2014 13:09:53 UTC+2, Akka Team a écrit : >>> >>> Hi, >>> >>> >>> >>> >>>> As PersistentImpl is private, it seems very delicate to write a >>>> serializer for it. >>>> >>> >>> As the wrapper above is a sensitive internal class you should definitely >>> not try to serialize it in a custom way. If you need finer grained control >>> of your journal format you have to write a journal plugin. >>> >>> >>>> >>>> So how can I get a clean output ? >>>> If I can't, what's the point to allow configuration for custom >>>> serializer ? >>>> >>> >>> The point is that you have more control about the compatiblity of your >>> event data between versions, for example by carefully constructing your >>> persistence data format in protobuf. Also, java serialization is slow. >>> >>> -Endre >>> >>> >>>> >>>> Thanks for help. >>>> >>>> -- >>>> >>>>>>>>>> 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. >>>> >>> >>> >>> >>> -- >>> Akka Team >>> Typesafe - The software stack for applications that scale >>> Blog: letitcrash.com >>> Twitter: @akkateam >>> >> -- >> >>>>>>>>>> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Cheers, > Konrad 'ktoso' Malawski > hAkker @ Typesafe > > <http://typesafe.com> > -- >>>>>>>>>> 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.
