Open blackjack26 opened 8 years ago
That kinda defeats the point of WhereClause
though...
oh oh oh! Here's one. Okay, instead of making it an optional constructor, we instead update the SqlStatement to contain a function "where(String clause)". This way you don't need to go SqlStatement.where(new WhereClause('AND df <> true'));
but SqlStatement.where('AND df <> true'));
or make the optional constructor package-private so SqlStatement.where("AND df <> true");
reads where(String clause) { where.add(new WhereClause(clause); }
taking that extra step out for the developer who is using this method, but also allows for the flexibility of needing the constructor after all, in which case you would add "public" in front of the optional constructor.
With either idea, we would be able to make the SqlStatement.where
be able to create several where clauses at once, meaning someone could literally type out the whole where WHERE df <> true AND cf = true AND tid = 1
and it'd generate all 3 clauses.
I was just making a quick scratch up to see how this would look like and realized that these ideas have no way of conveying the valueDataType
and thus puts the whole idea on hold until it is worked out a clean, non-obtrusive way to declare the type.
Meaning, the code for the constructor & function will be in there on my next commit, but are commented out.
Or, instead of a constructor, we could have a "parse" function, so it's like "WhereClause.parse(String clause)"
When creating a WhereClause object, to make syntax shorter there could be an optional constructor in which you pass in some sort of string that sets the internal variables of the object.
Ex: