On 28.08.14 12:00, Roland Kuhn wrote:
Hi Martin and Alex,
the point you raise is a good one, I did not include it in my first
email because defining these common (and thereby de-facto required)
queries is not a simple task: we should not include something that
most journals will opt out of, and what we pick must be of general
interest because it presents a burden to every journal implementor—at
least morally.
My reasoning for keeping persistenceIds and arbitrary named streams
separate is that persistenceIds must be supported in a fully
linearizable fashion whereas named streams do not necessarily have
this requirement; on the write-side it might make sense to specify
that persistenceIds are only ever written to from one actor at a time,
which potentially simplifies the Journal implementation. This also
does not hold for named streams.
I agree, makes sense to keep QueryByPersistenceId a separate type.
Concerning types I assume that there is an implicit expectation that
they work like types in Java: when I persist a ShoppingCartCreated
event I want to see it in the stream for all ShoppingCartEvents. This
means that the Journal needs to understand subtype relationships that
in turn have to be lifted from the programming language used. It might
be that this is possible, but at least it is not trivial. Is it
reasonable to expect most Journal implementations to support this?
I only included it in my proposal because it was discussed/requested
very often if I remember correctly. It may not be trivial to support
though. Fine for me if they're not pre-defined.
One query that we might want to include generically is the ability to
ask for the merged streams of multiple persistenceIds—be that
deterministic or not.
It can be pretty hard for some backend stores to support that in a
scalable way (i.e. that scales to a large number of persistenceIds) as
you cannot pre-compute the results because the persistenceIds are query
arguments.
Having a QueryByStream(name, ...) in additition to QueryByPersistenceId
is much less of a burden and serves a wide range of use cases.
Another thought: there should probably be a trait JournalQuery from
which the discussed case classes inherit, and we should specify that
the Journal is obliged to reply to all such requests, explicitly
denying those it does not implement.
+1
Regards,
Roland
28 aug 2014 kl. 11:12 skrev ahjohannessen <[email protected]
<mailto:[email protected]>>:
Hi Martin,
On Thursday, August 28, 2014 8:01:43 AM UTC+1, Martin Krasser wrote:
In your summary, the only query command type pre-defined in
akka-persistence is QueryByPersistenceId. I'd find it useful to
further pre-define other query command types in akka-persistence
to cover the most common use cases, such as:
- QueryByStreamDeterministic(name, from, to) (as a generalization
of QueryKafkaTopic, ... and maybe also QueryByPersistenceId)
- QueryByTypeDeterministic(type, from, to)
- QueryByStream(name, fromTime)
- QueryByType(type, fromTime)
Supporting these commands would still be optional but it would
give better guidance for plugin developers which queries to
support and, more importantly, make it easier for applications to
switch from one plugin to another. Other, more specialized
queries would still remain plugin-specific such as
QueryByProperty, QueryDynamic(queryString), etc ...
I think it is a great idea to standardize on common cases such as
those you line up, because it gives guidance and reduces one-off
fragmentation among journal APIs. It is reasonable that
akka-persistence sets some sort of standard with respect to general
use cases of reading streams.
--
>>>>>>>>>> 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]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
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 <http://typesafe.com/> – Reactive apps on the JVM.
twitter: @rolandkuhn
<http://twitter.com/#%21/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 [email protected]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Martin Krasser
blog: http://krasserm.blogspot.com
code: http://github.com/krasserm
twitter: http://twitter.com/mrt1nz
--
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.
