Lutger pisze:
yigal chripun wrote:
aarti_pl Wrote:
....
There's nothing more hideous than all those frameworks in Java/C++ that
try to re-enginer SQL into functions, templates, LINQ, whatever. SQL *is*
a perfectly designed language for its purpose and it doesn't need to be
redisnged! The only problem with this is the type-safety when embedding
sql as string in a host language. the solution is two-phased:
I disagree. There are a couple of problems with using Sql strings inside
regular code:
- no help from the IDE whatsoever. Imagine writing your D program in
notepad, then instead of compiling it in advance, you compile it at runtime:
losing all benefit from the static type checking and whatever the IDE offers
you (highlighting and autocomplete). This would be completely absurd yet you
prefer it with sql? Of course you can write queries in a specialized
environment, somewhat better but it also sucks.
Thanks for this post. It is basically answer to other (rather
dismissive) posts.
In addition to what you said, you get from IDE also possibility to
refactor your database columns/names/types etc. All with static checks
in your code. After change you know immediately what should be changed.
(*it is possible at least in my framework, I don't know if it is
possible in other frameworks).
- mapping relational data to objects is a sucky, boring, lengthy and error
prone task.
In my experience a simple ORM tool such as Linq-to-Sql makes life so much
easier. RoR has this too, it's a blessing.
Now if you want to do a big part of your logic on the database instead of
simply using it as storage, that may be a different story. (I still think it
sucks though)
Well, I have different view on this. Personally I think that it is much
better (faster, easier) to pass tables in the application.
But after defining SQL query (in object oriented way) you can do
whatever you want: you can change your SQL object into table of data or
into objects.
You can also use these object oriented queries to generate different SQL
dialects for different databases or you can generate hashes for using
them as keys in your cache.
Additionally in my framework you can pass around parts of SQL e.g. :
WhereExpression exp = Where(More(visitcards.id, 100));
You basically *CAN NOT* do it when just using strings. So I think such a
way of defining DSLs in mother language have its merits. String is not
enough.
phase a is simple, look at the C# API for postgres (I think). The query is
one string like: "select * from table where :a > 42", the :name is a place
holder for the host-language variable, and you call an API to bind those
:names to variables in a type-safe way. the downside is that it's verbose.
phase b is what Nemerle does with the above - it has an AST macro to wrap
the above so you can write your query directly and it is checked as
compile-time.
No operators were abused in implementing this.
I fail to see how this is any different than Linq. Granted, you just
reproduce the SQL language and ignore any mapping to Objects, but other than
that it is just the same but with a different technology. (Linq is not only
about abstracting sql by the way, it does a lot more)
I would like to add that probably many of DSL languages would never be
created if mother languages would be expressive enough.
And additionally, can any of opponents explain what is so wrong with
operator overloading suggested by me in last emails? (Pseudocode - I
didn't check exact syntax):
RES opInfix(alias str)(T val) {
...
}
...
auto expr = Where((visitcards.id `>` 100) `AND` (visitcards.surname
`Like` "A*"));
(Please note that when overloaded operator is used it is denoted with ``
(it can be probably any definition of string). I think it would be good
enough solution and thanks to this operator overloading will be clearly
visible in calling code).
And dear opponents please propose how to solve above mentioned problems
with DSL languages as strings ;-) If there will be a way to solve all
those problems cleanly - I am all for not using operator overloading :-)
Best Regards
Marcin Kuszczak
