Branch 0.8 #16
Branch 0.8 #16
Conversation
| BinPredOp := EQ | NEQ | GT | LT | GEQ | LEQ | ||
| RefColOp := IN | NOTIN | ||
| RefRangeOp := BETWEEN | NOTBETWEEN | ||
| RegexOp := LIKE | ||
| ``` |
There was a problem hiding this comment.
Well, I tried to fix this Backus–Naur form in order to describe actual form of criteria
But now it looks a little bit complicated and actually I think it should be (just look at the formal expressions of postgresql commands😁)
In my opinion, we could exclude this theoretical part from README and add more practical examples below🙂
What do you think?
There was a problem hiding this comment.
yeaa.. well, actually it isn't necessary to be a perfect Bakus-Naur form at the moment. It could be just tentative following a pseudo-bn form.
I was thinking in something like that:
Criteria := Conjuction Criteria Criteria | Predicate | Value<Boolean>
Predicate := UnaryPred Ref | BinaryPred Ref Ref
Ref := Value<T> | Col
Conjuction := AND | OR
UnaryPred := IS_NULL | IS_NOT_NULL ...
BinaryPred := EQ | NEQ | GT | LT | GEQ | LEQ | IN | LIKE ...
We can iterate over this in the future. I don't mind to exclude it from README, but I would like to persist it in somewhere just to keep in mind or at least pointing the PostgreSQL expression reference.
Something like "Following the formal definition of blabla..." 😅
There was a problem hiding this comment.
okay, I get it, then I'll make it as you say :)
| trait Collection[D <: CriteriaTag, +V] extends Ref[D, Seq[V]] | ||
| trait Col[D <: CriteriaTag] extends Ref[D, Column] | ||
| trait Bool[D <: CriteriaTag] extends Value[D, Boolean] with Criteria[D] | ||
| trait Range[D <: CriteriaTag, +V] extends Ref[D, (V, V)] |
There was a problem hiding this comment.
Again, I copy-paste the question written in the older PR:
I have a question just to really understand the reason. Why did yo switch the position of the Value type constructors? Was it just for aesthetics? in order to fix the same position the same constructor (always the D on the left and the rest on the right? or was it because of some Variance/Covariance position reason?
There was a problem hiding this comment.
well, it was just for aesthetics, but I think covariance is redundant here, I'll fix it (don't remember why did i do it🤔)
| } | ||
|
|
||
| class Column(val colName: String) extends AnyVal |
There was a problem hiding this comment.
(The same copy-paste question)
Here just a question, why do not define Column as another trait? Will it be used for something else apart of typing the column expressions? Will the colName parameter be uses for something particular? And if it will, Why didn't you define it as a case class? I mean, it's just to know your point of view 😉
| class Column(val colName: String) extends AnyVal | |
| trait Column |
or
| class Column(val colName: String) extends AnyVal | |
| case class Column(colName: String) extends AnyVal |
There was a problem hiding this comment.
I don't like the idea to use trait here as it should be just a new type of string to use implicits for it
I guess the second variant you suggest is the best choice here
build.sbt
Outdated
| @@ -28,3 +30,4 @@ lazy val examples: Project = | |||
| name := "criteria4s-examples" | |||
| ) | |||
| .dependsOn(core, sql) | |||
| .withKindProjector | |||
There was a problem hiding this comment.
add a blank line please :)
| BinPredOp := EQ | NEQ | GT | LT | GEQ | LEQ | ||
| RefColOp := IN | NOTIN | ||
| RefRangeOp := BETWEEN | NOTBETWEEN | ||
| RegexOp := LIKE | ||
| ``` |
There was a problem hiding this comment.
yeaa.. well, actually it isn't necessary to be a perfect Bakus-Naur form at the moment. It could be just tentative following a pseudo-bn form.
I was thinking in something like that:
Criteria := Conjuction Criteria Criteria | Predicate | Value<Boolean>
Predicate := UnaryPred Ref | BinaryPred Ref Ref
Ref := Value<T> | Col
Conjuction := AND | OR
UnaryPred := IS_NULL | IS_NOT_NULL ...
BinaryPred := EQ | NEQ | GT | LT | GEQ | LEQ | IN | LIKE ...
We can iterate over this in the future. I don't mind to exclude it from README, but I would like to persist it in somewhere just to keep in mind or at least pointing the PostgreSQL expression reference.
Something like "Following the formal definition of blabla..." 😅
No description provided.