Query mechanism for Akka.Persistence SQL-based journals #1306
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Weird... why didn't the build server pick this up? |
|
Ah, figured it out - the timestamp of this commit is from August 18th, so TC won't pick it up. Could do the following and update the timestamp to present time? http://stackoverflow.com/questions/454734/how-can-one-change-the-timestamp-of-an-old-commit-in-git |
Horusiath
force-pushed
the
sql-persistence-queries
branch
from
bee63d4
to
ae51135
Compare
|
@Aaronontheweb all tests except those, which require SQL Server to be initialized, have passed. |
Horusiath
force-pushed
the
sql-persistence-queries
branch
from
ae51135
to
9c1ae6e
Compare
|
I've introduced few more changes:
|
|
error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. |
Horusiath
force-pushed
the
sql-persistence-queries
branch
2 times, most recently
from
e791534
to
18a5b98
Compare
Motivation: One of the popular problems related to Akka.Persistence is support for aggregation of events across multiple persisted streams. Since partitioned journals are part of the Akka.Persistence plugin design, this is hard to achieve using generic tools. Instead each journal provider should be allowed to define set of querying operations, it supports. Purpose of this commit is to introduce common set of querying messages to be used by all SQL-backed journals. This has been provided in form of Query message, which can take a collection of IHint parameters, that are used to specify filters around queried events. Currently there are three of them possible: - Query by provided persistence id collection. - Query by provided message manifest - manifest is often correlated with message type, but in this case it's won't take a inheritance rules when filtering a message. - Query by message timestamp range - range can be one-side open or closed one. Range is always left-side inclusive (From) and right-side exclusive (To) in order to avoid resending the same events in sliding window scenarios. In result, journal will emit each IPersistentRepresentation containing an event wrapped in QueryResponse message. End of the transmission will be signaled by QuerySuccess message and any possible errors will cause QueryFailure to used as a reply. Additional changes: In addition this commit fixes issue with concurrent access to SQL transaction by creating a dedicated sql connection object for each request. BREAKING CHANGES: The biggest change is modification of existing SQL table schemas - 'payload_type' field has been renamed to 'manifest' and aditional 'timestamp' field has been added. Another change is a generic 'SqlJournal' class that can be used as base class for incomming journal implementations for any future specific SQL providers. Also dependent types (like 'JournalDbEngine' and 'IQueryBuilder') have been changed to make querying possible.
Horusiath
force-pushed
the
sql-persistence-queries
branch
from
18a5b98
to
7cd4f79
Compare
|
@rogeralsing @Aaronontheweb Builds are passing. Could you review the changes? |
rogeralsing
added a commit
that referenced
this pull request
Oct 31, 2015
Query mechanism for Akka.Persistence SQL-based journals
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
WARNING: this PR contains breaking changes for SQL-based plugins. After merging, changes should be applied in dependent sql plugins. Querying mechanism should also be documented.
Changes regarding Akka.Persistence
Akka.Persistencemessages from now implement structural equality and meaningfullToStringmessages.ITestOutputHelperfor spec output logging.Changes regarding Akka.Persistence.Sql.Common
Querymessage. Message may contain set oIHintinstances used to filter the data (currently only Manifest field and collection of PersistenceIds are supported, more to be written in the future). Response is collection ofQueryResponsemessages containing events filtered for query followed byQuerySuccessmessage which finishes response transmission. If an error occurred final message send isQueryFailuremessagePayloadTypehas been renamed toManifest. Now it's more general and can contain user defined manifests if necessary.SqlJournalclass. This simplifies further plugin development and handles query messages.Akka.Persistence.Sql.Common.TestKitthat containsSqlJournalQuerySpecto be inherited by dependent plugins specs in order to verify if querying is working correctly.Changes regarding Akka.Persistence.SqlServer
Akka.Persistence.SqlServeris again joined into core repo - reason for that is thatAkka.Persistence.Sql.Commoncontained dead code, that was not used/tested anywhere in core solution. Me and @rogeralsing agreed that at least one sub-plugin should be presented here.Akka.Persistence.Sql.Commonlib.Warninglevel info, if used connection string don't specify MultipleActiveResultSets=True, as it may be reason of future problems. /cc Multiple active result sets exception #1291Errorlevel if after insertion command will return result other than 1 for any reason (which is not a desired behavior).