-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Institutions cassandra #1013
Institutions cassandra #1013
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1013 +/- ##
=========================================
Coverage ? 93.13%
=========================================
Files ? 291
Lines ? 3830
Branches ? 73
=========================================
Hits ? 3567
Misses ? 263
Partials ? 0
Continue to review full report at Codecov.
|
Smoke tests for this PR look good, both locally and on Docker-Compose. I still need to take a closer look at the code, but I wanted to say 👍 so far. I did notice a long
|
Thanks @schbetsy. I would be surprised if that error is related to this PR, maybe it requires a bit more investigation. |
|
||
retry-unsuccessful-join-after = 20s | ||
|
||
//DON'T USE IN PRODUCTION!!!!! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What will this value be in production? Why do we need a temporary value here now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Auto downing of nodes is not recommended in production systems due to the possibility of network failures that form a partition in the cluster. It's useful in development so that the cluster lifecycle (joining, unreachable, leaving, etc. ) can be tested
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay. Let's make sure there's an open issue in GH to remind us to update that value before we go to production.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Created. #1017
cassandra { | ||
host = "127.0.0.1" | ||
host = ${CASSANDRA_CLUSTER_HOSTS} | ||
port = 9142 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sometimes the Cassandra port is set to 9142
and sometimes 9042
. I haven't figured out the pattern for which should be used where. What's the logic?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a mistake from a previous try. CassandraUnit
uses 9142, but we're not using it when running the application. Will change back to default port
|
||
def preparedStatement(implicit session: Session): PreparedStatement = { | ||
session.prepare(s"INSERT INTO $keyspace.institutions" + | ||
s"(id," + |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lines 23-51 don't have substitutions on them, so they probably don't need the s
before the "
.
|
||
class InstitutionCassandraProjection extends InstitutionCassandraRepository { | ||
|
||
def startUp(): Unit = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I'm understanding this method correctly. It looks like, when the system starts up (in HmdaPlatform.scala
), it uses this method to replay all of the Institution-related events from the read journal into Cassandra.
Is that the case? Can you give any more context to help clarify?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This starts up a stream of events from the journal, yes. The difference from previous implementations (i.e. what happens in validation) is that this stream is running continuously, listening to changes in the journal to push those events to the read model. One part that we haven't done yet (because it's not really 100% clear yet what the requirements are) is storing snapshots as an optimization, so not every event has to be read back to the read model.
session.execute(query) | ||
} | ||
|
||
override def insertData(source: Source[InstitutionQuery, NotUsed]): Future[Done] = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the insertData
and readData
methods are currently used in a spec (InstitutionCassandraRepositorySpec
), but they aren't called explicitly from anywhere else in the code. Is this another case where they're called implicitly somewhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not right now. Both of those are convenience methods. Reading will happen when we introduce publication (down the road) and the write method is useful if we need to populate a panel file directly (i.e. for historical data)
|
||
cassandra { | ||
host = "127.0.0.1" | ||
port = 9142 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this port also change from 9142
to 9042
?
|
||
cassandra { | ||
host = "127.0.0.1" | ||
port = 9142 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same question as above about port 9142
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, because EmbeddedCassandraServerHelper
uses port 9142
for tests
I've seen this in the Travis output during the specs, but it doesn't come up when I run the specs locally.
This is new as of this PR, right? Any idea where it might be coming from? |
We'll merge this around midday tomorrow, even if Travis doesn't pass. Tests pass locally and smoke tests look good, so we're calling this safe to merge. |
build.sbt
Outdated
@@ -162,7 +162,8 @@ lazy val query = (project in file("query")) | |||
oldStrategy(x) | |||
}, | |||
parallelExecution in Test := false, | |||
libraryDependencies ++= configDeps ++ akkaPersistenceDeps ++ slickDeps | |||
fork in Test := true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like this line is causing the java.io.EOFException
that causes the "sbt.ForkMain failed with exit code 137" error in Travis.
Is forking necessary in the query
project's specs? If so, why?
EDIT: Well, I can't actually confirm that this line is causing the error. But my question still stands.
EDIT2: Anecdotally, I removed fork in Test := true
on a test branch, and tests all passed in Travis.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Source: I learned more about this error by reading this GH issue from SBT.
Closes #1012
Doesn't remove
PostgreSQL
implementation yet