-
Notifications
You must be signed in to change notification settings - Fork 12
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
Issue/JCES-1896 Adding isWrite information to API #49
Issue/JCES-1896 Adding isWrite information to API #49
Conversation
|
Can we start from the context? Why do we need to know if it's a read/write operation? Some operations may be read-only but will never reach replica. It also depends on the context.
|
Context is, that for resource owner(REST endpoint/ amq/other) we want to let them monitor their endpoints whether actually, they are readonly, and later help them maintain that readability, to give them API that they can implement a way how to react if somebody broke their resource and make it none-readonly again, thats the idea. So the question is?
What's the reason? Isn't permanent, or temporary(early stages of db-replica evolution), mixed? I can imagine that explaining the full context might be tricky and there is still some space to discover and learn about it. |
src/main/java/com/atlassian/db/replica/internal/ReplicaStatement.java
Outdated
Show resolved
Hide resolved
src/main/java/com/atlassian/db/replica/internal/SQLOpeartionType.java
Outdated
Show resolved
Hide resolved
src/main/java/com/atlassian/db/replica/internal/SQLOpeartionType.java
Outdated
Show resolved
Hide resolved
src/main/java/com/atlassian/db/replica/internal/SQLOpeartionType.java
Outdated
Show resolved
Hide resolved
src/main/java/com/atlassian/db/replica/internal/SQLOpeartionType.java
Outdated
Show resolved
Hide resolved
src/main/java/com/atlassian/db/replica/internal/SQLOpeartionType.java
Outdated
Show resolved
Hide resolved
src/main/java/com/atlassian/db/replica/internal/SQLOpeartionType.java
Outdated
Show resolved
Hide resolved
src/test/java/com/atlassian/db/replica/api/reason/TestRouteDecision.java
Outdated
Show resolved
Hide resolved
src/main/java/com/atlassian/db/replica/internal/ReplicaStatement.java
Outdated
Show resolved
Hide resolved
src/main/java/com/atlassian/db/replica/internal/ReplicaStatement.java
Outdated
Show resolved
Hide resolved
I described the use case in #50 |
It seems the resource owner wants to know if queries are landing on replica or main and not if the queries are read-only or not. The API to do that already exist, if
REPLICA_INCONSISTENT -> it's outside of control for a single endpoint. |
src/main/java/com/atlassian/db/replica/internal/ReplicaStatement.java
Outdated
Show resolved
Hide resolved
src/main/java/com/atlassian/db/replica/internal/RouteDecisionBuilder.java
Outdated
Show resolved
Hide resolved
In my opinion Resource owner would like to know what it can do to make resource RR compatible Full data (the data might change as db-replica implementation will growth and make decision more complicated) :
So for REPLICA_INCONSISTENT and MAIN_CONNECTION_REUSE what information Resource owner should receive? |
The resource owner will get the SQL. The user can also capture a stack-trace. We can't provide more information than that. All our internal classifications will always be less accurate than this (SQL query and context are inputs). And then there are two cases:
REPLICA_INCONSISTENT -> Consistency of the replica reduces the effectiveness of the library. The user can experiment with better consistency implementations or with losing some requirements. MAIN_CONNECTION_REUSE -> it will always come with a reason. It means it was already decided, and the current decision doesn't matter. User can dig into the cause
It never was. |
I've reused stateListner to learn more about states changed behind the scene. It was much more productive than debugging. |
e5dfced
to
c2cb4cc
Compare
src/main/java/com/atlassian/db/replica/api/reason/RouteDecision.java
Outdated
Show resolved
Hide resolved
src/main/java/com/atlassian/db/replica/api/reason/RouteDecision.java
Outdated
Show resolved
Hide resolved
src/main/java/com/atlassian/db/replica/internal/ReplicaStatement.java
Outdated
Show resolved
Hide resolved
src/main/java/com/atlassian/db/replica/internal/ReplicaStatement.java
Outdated
Show resolved
Hide resolved
src/test/java/com/atlassian/db/replica/api/TestDualConnection.java
Outdated
Show resolved
Hide resolved
src/test/java/com/atlassian/db/replica/api/TestDualConnection.java
Outdated
Show resolved
Hide resolved
src/main/java/com/atlassian/db/replica/internal/ReplicaStatement.java
Outdated
Show resolved
Hide resolved
51832fc
to
631b6bb
Compare
1a7bfec
to
b793b34
Compare
src/main/java/com/atlassian/db/replica/internal/ReplicaStatement.java
Outdated
Show resolved
Hide resolved
cea5801
to
f807cfc
Compare
src/main/java/com/atlassian/db/replica/api/reason/RouteDecision.java
Outdated
Show resolved
Hide resolved
357e9d7
to
e4bb2fc
Compare
…on on compile lvl to Reason and make it main source of truth for isWriteOperation. Introduced SqlQuery with OO goodness. Only (RW_API_CALL, WRITE_OPERATION) are Write reasons, rest is Read reasons, but might be run on MAIN due to connection state and other condtions
5f2ee15
to
bd0a683
Compare
src/main/java/com/atlassian/db/replica/api/reason/RouteDecision.java
Outdated
Show resolved
Hide resolved
…n.isWrite(), introducing SqlQuery to improve OO impl
64c2001
to
e3db3db
Compare
e3db3db
to
147f99b
Compare
@wyrzyk because you requested change requested I need your response to move forward with PR |
JCES-1896 draft - I'm trying to find the ultimate answer for how to judge whether sql is read/write and where is best place (is there possibility to increase coverage by more readQueries moved to Replica). How SQL operation is treated in db-replica is based on statementType + sql + consistency. Is there a way to arbitrarily judge whether SQL is read/write?