-
Notifications
You must be signed in to change notification settings - Fork 0
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
#35: Refactor the core for more logical structure #36
#35: Refactor the core for more logical structure #36
Conversation
* massive classes refactoring
…maybe it's a step from different galaxy :-D
…refactor-the-core-for-more-logical-structure
|
JaCoCo code coverage report - scala 2.12.17
|
JaCoCo code coverage report - scala 2.11.12
|
core/src/main/scala/za/co/absa/fadb/statushandling/FunctionStatus.scala
Outdated
Show resolved
Hide resolved
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.
- Pulled
- Built
- Test ran
- Code review (not enough insight into advance scala for this)
- tests code review
- test coverage analysis
core/src/main/scala/za/co/absa/fadb/statushandling/StatusHandling.scala
Outdated
Show resolved
Hide resolved
core/src/main/scala/za/co/absa/fadb/statushandling/StatusHandling.scala
Outdated
Show resolved
Hide resolved
core/src/main/scala/za/co/absa/fadb/statushandling/StatusHandling.scala
Outdated
Show resolved
Hide resolved
core/src/main/scala/za/co/absa/fadb/statushandling/fadbstandard/StandardStatusHandling.scala
Outdated
Show resolved
Hide resolved
examples/src/main/scala/za/co/absa/fadb/examples/enceladus/DatasetSchema.scala
Outdated
Show resolved
Hide resolved
trait SlickPgFunction[T, R] extends DBFunctionFabric { | ||
|
||
protected def sqlToCallFunction(values: T): SQLActionBuilder | ||
/** | ||
* A reference to the [[SlickPgEngine]] to use the [[za.co.absa.fadb.DBFunction]] with |
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.
DBFunction link not working
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 think this doesn't work because it goes to a different module and searches on the not-yet-released doc.
|
||
/** | ||
* An extension of the [[SlickPgFunction]] mix-in trait to add support of status handling | ||
* This trait expects another mix-in of [[za.co.absa.fadb.statushandling.StatusHandling]] (or implementation of `checkStatus` function) |
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.
StatusHandling link not working.
|
||
/** | ||
* Function which should actually check the status code returned by the DB function. Expected to got implemented by | ||
* [[za.co.absa.fadb.statushandling.StatusHandling]] successor trait. But of course can be implemented directly. |
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.
Link not working.
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.
- Pulled
- Built
- Test ran
- Code review (not enough insight into advance scala for this)
- tests code review
- test coverage analysis
* @tparam R - return the of the query | ||
* @return - sequence of the results of database query | ||
*/ | ||
def unique[R](query: QueryType[R]): Future[R] = { |
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 thinking about whether to name this as executeOne
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 like 'execute' as prefix
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 on the other hand like them distinguished. 😉 Easier to read. and also nicely binds to the successor classes.
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 don't think option
is easier to read. It's not intuitive. We are actually executing a SQL query here.
In regards to the unique
... it's kind of better, but still, I don't really like it that much.
Let's have an inspiration from some most famous DB libraries out there. For example SQLAlchemy. There are functions like fetchOne
, executeMany
etc - https://peps.python.org/pep-0249/#executemany and I think that's much better, because it not only says what the result kind of should be, but also it says about what is actually happening. Does it make sense?
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.
OK, Will think about the names 👍
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.
Agreed to do the renames as part of #34
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
Co-authored-by: Ladislav Sulak <laco.sulak@gmail.com>
This exception does't have a companion object with
just saying, all exceptions have this, so it's inconsistent. But I don't strictly insist on changing it, up to you |
core/src/main/scala/za/co/absa/fadb/statushandling/UserDefinedStatusHandling.scala
Show resolved
Hide resolved
} | ||
|
||
override protected def sqlToCallFunction(values: (String, Option[Int])): SQLActionBuilder = { | ||
override protected def sql(values: (String, Option[Int])): SQLActionBuilder = { |
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's this Option[Int] for? If it's schema name an version, then according to the Schema
case class, they are both mandatory:
schemaName: String,
schemaVersion: Int,
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 thought it was in some description.
Version is mandatory with the schema (any entity), but when not provided, the latest version is returned.
Then it's perfectly OK, to use None
= Null
= unknown/undefined in the query, me thinks.
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.
ooh okay. Yeah perhaps some quick code doc can be useful for these examples then. But I know that we'll rework it anyway..
examples/src/main/scala/za/co/absa/fadb/examples/enceladus/DatasetSchema.scala
Show resolved
Hide resolved
} | ||
|
||
final class ListSchemas(implicit schema: DBSchema[ExecutorEngineType]) | ||
extends DBSeqFunction[ExecutorEngineType, Boolean, SchemaHeader](schema) | ||
final class List(implicit override val schema: DBSchema, override val dbEngine: SlickPgEngine) |
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 know that this is just an example but maybe it can be further improved?
Why ListSchemas
-> List
? List
is quite general and the name can be both verb (list/enumerate something) or a noun (list as a data type). I would prefer ListSchemas
or ListSchemaHeaders
if you want
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.
Yeeaah.
Well the examples were created for Enceladus migration to Postgres. Then the function name in the DB model in that PR were changed. But before reflecting it here, the whole migration was shelved.
The examples confidently show some interesting methods how the DBFunction
successors can operate:
- having or not having status support
- defining additional
apply
function - overriding the existing one
So they might serve some benefit until Standalone rerunable examples #9 is delivered.
But I wanted to test it against the Enceladus DB model, just to verify, the refactoring works in practice, not just compilation. That's why the rename... Might be rolled back. 🤔
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 I kind of thought so. Well, since there is this #9, which will change everything, I don't mind keeping as is. Maybe, if you are up for it, add some brief code doc, maybe 1-2 sentences can be enough. But up to you - I at least wanted to have some understanding and now I have :)
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.
The examples confidently show... -> The examples coincidentally show...
final class ListSchemas(implicit schema: DBSchema[ExecutorEngineType]) | ||
extends DBSeqFunction[ExecutorEngineType, Boolean, SchemaHeader](schema) | ||
final class List(implicit override val schema: DBSchema, override val dbEngine: SlickPgEngine) | ||
extends DBSeqFunction[Boolean, SchemaHeader, SlickPgEngine]() |
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.
Why the status support/handling were not used here? What's different there? I think that 'list' operation is similar to 'get' i.e. the DB function should return some status code and status text for us?
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.
list
operations returning a number of results and being strictly read-only, don't have to have status results. I still prefer that, while I think @Zejnilovic less.
Anyway, here it works again as an example - status is not mandatory.
In Unify we can (and should) still discuss this concept ❗
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 talk about it. I think, after re-reading of https://docs.google.com/document/d/1gYVg6y9Ug4EC5CKSm7sRZ0bN5nv5Eeta_YiVGBoHP4A/edit#, that a pure select
operations don't have to have the status code / handling around it. But if there is a chance that a given DB function is doing more then a select, then the status codes are relevant. We can discuss outside of this PR
examples/src/main/scala/za/co/absa/fadb/examples/enceladus/DatasetSchema.scala
Show resolved
Hide resolved
...src/test/scala/za/co/absa/fadb/statushandling/fadbstandard/StandardStatusHandlingSuite.scala
Show resolved
Hide resolved
I think that it's fine but if you want we can discuss, definitely 👍 |
It's a case class, with automatic |
examples/src/main/scala/za/co/absa/fadb/examples/enceladus/DatasetSchema.scala
Show resolved
Hide resolved
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.
The review finished. Just some minor points about potential code docs, otherwise it looks good to me!
I didn't test it - just pulled, build, ran tests, and did the review.
examples/src/main/scala/za/co/absa/fadb/examples/enceladus/DatasetSchema.scala
Show resolved
Hide resolved
…asetSchema.scala Co-authored-by: Ladislav Sulak <laco.sulak@gmail.com>
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.
Really good work, I think that it's time to merge it :)
DBExcecutor
changed toDBEngine
, the core and db engine (Slick at the moment) responsibility parts better separatedDatasetSchema
example classCloses #35