Hi all, I fully agree that it is a valid feature.
Would the following sketch work? - Keep PersistentView poll based, but let it query for events with a specified "tag" instead of a single persistenceId. This requires a new query in journal api. - Add optional tags parameter to persist and persistAsync, i.e. when storing an event it can be marked with zero or more tags. This requires adding tags field to PersistentRepr. - Streams on top of PersistentView The new view query would have to include a Map of persistenceId -> seqNr. The journal actor is supposed to be local, so the size of this Map should not be a problem. Is it overkill to tag individual events? Should the tags be per PersistentActor instance instead? As a second step (or immediately?), we could let the journal push events to the view. Most journal implementations will have to implement this with polling anyway, but then we make it possible for a journal to take advantage of native push from the store. The view would have to request number of events from the journal to handle backpressure (similar to reactive streams). Regards, Patrik On Tue, Jul 29, 2014 at 10:46 AM, Konrad 'ktoso' Malawski < konrad.malaw...@typesafe.com> wrote: > > - a total order per persistenceId based on sequence numbers (= partial > ordering in the "all events" stream) is a must have IMO. > - ordering based on timestamps should be an application level concern (= > timestamps in application-defined events and (re-)ordering done by > application) > > Agreed, seqNrs are at our core and we’ll stick to them (partial ordering > will be in for sure, was thinking if more was needed by app implementors). > Bringing in timestamps “in some case” would be inconsistent with the rest > of persistence anyway, so pushing it into user land sounds good. > > Actually, since we want to expose this as reactive streams the timestamp > ordering could be expressed as `merge(streams, userLandProvidedOrdering)` > (we don’t have this yet)… Tempting idea, looking forward to trying out > different things there. > > - mid/long-term goal: causal ordering (allows moving from eventual > consistency to causal consistency). See also Don't Settle For Eventual > Consistency <http://queue.acm.org/detail.cfm?id=2610533>. > > Thanks! Have not read that one yet - looks very interesting. > Will catch up with it today :-) > > > — k > > -- > >>>>>>>>>> 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. > -- Patrik Nordwall Typesafe <http://typesafe.com/> - Reactive apps on the JVM Twitter: @patriknw -- >>>>>>>>>> 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.
