-
Notifications
You must be signed in to change notification settings - Fork 0
Vision
This page should offer the vision where the Fa-DB library is seen to go.
As mentioned at the initial page in the README file the goal is to enable Scala programmers to access Database data in a seemingly natural way, without the need to write SQL queries mixed in the Scala code.
The vision is to continue making that easier and more seamless. While the libray is rather mature and already proved itself in applications, there's still enough to go forward with.
This is most of all about smoothing our the current state. Checking the documentation is sufficient on basic level, No known big bugs, no known big missing features etc.
Then the library can be released as version 1.0.
Right now the query had to be, at least partially, be composed by the creator of the Fa-DB function class. But it should be possible to do automatically based on the input data type I and the result data type R. The goal is, that in absolute majority of cases, to create an Fa-DB class (representing a DB function), it should be enough to specify its input and output parameter types, eventually the function name override.
Only in case of some overloaded functions the programmer might want to specify some additional apply functions.
This would probably require implementing some Scala macros.
Users might be interested in getting the data from the function in a given order and/or limited in size. Something the database can do more efficiently, probably. This would require adding the sorting and limiting ability to FaDBFunction et al. classes.
The sorting and limit can then be a property of the function class instance, by default not specified. And adding them would be kind of a copy constructor.
Alternatively the sorting and limiting could be optional parameters to the apply function. But it's not very Scala-like.
The current support for extended data types is ironically possible by the need to semi-manually construct the query. Once the automatic query composition is implemented, it would be needed to allow all kind of types translation, even custom ones, to their SQL counterparts - probably via type classes.
The library should be tested for reliability. This includes testing for all kind of data types both on input and output side. Also testing for connection failures, transaction failures etc. The goal is to relieve the user from having to create integrations tests verifying that the call of the particular Fa-DB function works as expected all the way down to the DB level.
Reliability would also be greatly improved by simplifying the check if the referenced DB function exists, has the expected signature and access rights. This could be developed to be a simple one-liner in the test code of the application accepting the Fa-DB functions class and the user(s) expected to have access to it. Underlying this would reconstruct the name and signature of the actual DB function and verify its presence and access rights in the connected database catalog. This could be done in coordination Balta library.
The functions of the core module too tightly depend on the DBEngine implementation and require specific engine successor to be defined. Ideally the two parts would be fully seperated.
The idea how to achieve the decoupling and offer new possibilities like apply functions of the Fa-DB class that accepts more parameters instead of a (case) class is inspired by Balta library. The DBEngine would have an interface function accepting function to execute, fields to select and a sequence of parameters to supply to the function. The sequence member would be the name of the parameter, value and sql expression for the type translation (if needed).
There are alternative DB engines and some users might prefer them to the current Doobie only implementation. Beside preference, they might offer other benefits.
This would bring great flexibility to the Library.
Right now only Postgres is a supported an underlying database. During the original conceptual design interest for other RDBes was voiced, namely MS-SQL.
It is repeatedly brought up to open up the DBEgine internals and allow calling the underlying DB functions more than one within the same transaction. While this might have some merit in the application processing logic, it breaks two of key benefits of the functional access to the DB (upon which the library is based upon) - scalability and consequently separation of concerns.
The ACID is a very powerful concept, but in cases it's limiting. When calling a function the application doesn't know and does not need to know if there is a single DB instance or a cluster of DB servers behind it. If the transaction is opened outside of the function call, the application needs to know about the DB topology and needs to manage the transaction accordingly. This breaks the separation of concerns and limits scalability.