Slashdot Mirror
Type Safety Coming To DB Queries
An anonymous reader writes "A new type-safe query language for the popular full-text search platform Solr, called Slashem (a Rogue-like), has just been released. Slashem is implemented as a domain-specific language in Scala, providing compile time type-safety, allowing you do things like date range queries against date fields but keeping you from trying to do a date range query against a string field. Hopefully this trend catches on, resulting in fewer invalid queries exploding at runtime."
It's rogue-like and the link to define "rogue" is to a fucking github page that says "lift/mongodb query dsl".
For fuck's sake... this tells people NOTHING. It's a completely useless article submission.
...Well, there's a namespace collision. There's Slashem and roguelike as referenced in the summary, and Slash'em and Roguelike as-in the Nethack-based game and the game genre. There's no way that wasn't intentional, and whoever's brilliant idea it was needs to be shot.
http://en.wikipedia.org/wiki/Roguelike
Rogue-like has already been used. It's very confusing to say your DB query language is like a video game.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
10 GOTO 10
Seven puppies were harmed during the making of this post.
Type-related problems in queries are generally pretty easy to catch in early testing. I don't put much stock in such technology and wish they would spend their efforts elsewhere. However, I imagine there are some niches where it makes a net positive difference.
Table-ized A.I.
The title is incorrect; type safety is already available in DB queries, at least on Windows clients. You can use LINQ directly in C# and VB, or standalone via LINQPad.
I'm all for new languages... but IMHO, I think LINQ is better. It looks more like SQL for all of us who already know SQL. It reads in the most logical order for word completion (select is after from/where, not before). And it's very carefully built on top of pure functional structures (SelectMany is equivalent to monadic Bind).
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
I think that description might have been CleverBot making an attempt on the Turing Test. What the hell?
Comment of the year
The domain-specific language should just be SQL itself, rather than some weird variant which is then used to generate some weird language with XML crap in it.
Embed SQL into the host language using a DSEL (domain specific embedded language), type-check it, then convert the AST to a the equivalent SQL string and send it to a server.
That's the right thing to do.
And it's trivial to do in a language like Scala or C++ (which is personally think is ironically more suited for DSELs than Scala).
Because as someone who writes SQL queries all day long and thinks this is silly, I now have a reason to feel superior. :-)
A post a day keeps productivity at bay.
nuff said
This appears to be more of the 'nanny state' mentality that Microsoft is shoving down our throats.
/rant
When a coder (or more accurately a DBA) puts dates in a string field, they usually have a good reason to do so. Preventing them from doing a date range query on their string field reduces their ability to function efficiently. Sure, it is elegant, but elegant usually means bigger, fatter and slower.
This is the old case of narrowing the band of opportunity so that the lowest performers can't make the obvious mistakes. When will they realise that they are also stifling the highest performers? Give us some credit folks. We're not all first year out of college.
The more xml I see the more I want to shoot something.
We are going in a weird direction, I am not saying it's right or wrong, but it's weirdly unpleasant and doesn't add simplicity to development, though of-course it depends what kind of development this is compared to. But I swear, the more levels of indirection is added with everything that cannot be simply executed in a debugger, the harder it's becoming to figure out what's happening quickly.
The point is that it seems to me that all these tools with multiple levels of indirection are aimed at more and more specialization, which may be fine with infinite resources on projects, but it's probably not fine in economic times, when fewer people are expected to handle more stuff.
You can't handle the truth.
Type errors in Solr queries don't strike me as a burning problem.
Don't worry, real developers have had just about enough of the Ruby on Rails/server-side JavaScript/DSL/Node.js/NoSQL/github know-nothings. They're starting to get shunned, and it's picking up steam.
There have been too many failed projects, too many unmaintainable systems, too many poor-performing applications, and too much data loss from this crowd. Everybody can and will make mistakes, and we do tolerate them now and then, but with these people it's one filthy fuck-up after another.
What's worse is that their chosen technologies are merely a half-assed way of avoiding the proper solution (which often takes some time and effort to learn).
Using Ruby on Rails is merely an excuse to avoid learning how to do proper web development. Server-side JavaScript is merely an excuse to avoid learning a real programming language that's suitable for back-end development, such as Java, C#, C++, Python or even goddamn Perl. DSLs are just an excuse to waste time building useless and unmaintainable libraries rather than doing real software development. Node.js is just an excuse to avoid learning how to use real web servers or application servers. NoSQL is just an excuse to avoid learning SQL and the proper use of relational databases. Github is just an excuse to avoid doing any sort of open source project management, including the basic task of preparing periodic releases.
It's only a matter of time before these fools have been completely run out of the industry. We'll go back to using real programming languages, real servers, real database systems, and get back to getting real work done.
playing on words to make the most confusing and least informative summery possible make sense?
I am sure people will go away with from this article thinking that this DB thing actually has something to do with randomly generated dungeons.
I know, how about we use alliteration in all of /.s articles from now on, at least that would be better then actually trying to confuse people.
Troll is not a replacement for I disagree.
I've been using LINQ for years and it's great. It's just like this Slashem concept but it's built-in to a manistream language: C#/VB. With LINQ you write your queries inline with the rest of your C# or VB code. They're not in a quoted string or separate resource file. You get the full syntax highlighting and intellisense as well as the red squiggly underline when you've done something wrong. They are type-safe and they play nicely with the language's collection classes. LINQ-to-Entities and LINQ-to-SQL are the variants that query databases (MySQL, Oracle, SQL Server, etc.). There are other variants like LINQ-to-XML and LINQ-to-Objects that can perform traditional relational queries against XML files or against your own objects and collections. You can mix and match these types of LINQ queries effortlessly. It's so powerful, easy to read and convenient that it has fundametally changed how I code.
I'd like some tools help with the generic of bad ideas like: deletes with no where usage of with grant option on objects grants of public to individual objects inserts of text into numeric fields (where we started) lots of joins without lots of index usage
How will getting the Amulet of Yendor get me type safety?
Doesn't SQLJ accomplish this for Java?
What is missing is the lack of ability of modern programming languages to grab type information from the database and generate new types on the fly.
Database types are per column, *AND* per tuple.
Every SQL query results in a new type, or an instance of a known type.
General purpose programming languages need to support sets as a first class object, as opposed to iterable collections. Do that, and you don't need hacky ORMs. But then, most modern "OO" languages aren't designed to be extensible.
I can throw myself at the ground, and miss.
I totally read that headline wrong.
PG'OCaml has been doing this for years: http://pgocaml.berlios.de/
"Moreover, it uses the describe feature of PostgreSQL to obtain type information about the database. This allows PG'OCaml to check at compile-time if the program is indeed consistent with the database structure. This type-safe database access is the primary advantage that PG'OCaml has over other PostgreSQL bindings for Ocaml."
This is nothing new.
A good database engines already has type checking, and so as long as your query language is type-safe and respects the types built-in to the database engine, then your query language will also be type safe. So all you need to do is write a library that can execute queries in a language like Haskell or Scala which makes use of static type checking, and you have got statically type-checked database queries.
Haskell has had its own database query library for years now, which works with several back-end databases including SQLite and MySQL.
select 1 where '2001-01-02 00:00:00'::text between '2001-01-01 00:00:00'::timestamp and '2001-01-05 00:00:00'::timestamp;
ERROR: operator does not exist: text >= timestamp without time zone
LINE 1: select 1 where '2001-01-02 00:00:00'::text between '2001-01...
^
HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts.
Hey whadya know, postgres has been doing this for years now.
--- It is not the things we do which we regret the most, but the things which we don't do.
So everybody hypes languages that are not type safe (JS, Python, PHP, etc.) and at the same time type safe SQL is considered interesting. Make up your minds!
Check out my cross-platform apps
Wonder how static typing manages to keep the developer from querying the day-of-death field instead of the day-of-birth field he wanted in the first place.
Hmmm, it does not, but most developers don't bother with this edge case bug, I mean the compiler catches it if I use the data wrongly, right?
You know what would really be cool is a boost style dimensional analysis system bound to schema meta data. Otherwise is it really necessary to invent a new a new language to introduce strict mode to existing query languages?
I'm not sure I understand the point of this extension: compile time type safety for internal (i.e., compiled) queries against a full-text database. Seems like a nice POC that has really no use in real life. The "rogue-like" moniker escapes me completely: is this some reference to database technology I'm not aware of? I just found it confusing.
Let me get this strait. You have a feature and you need to write some SQL queries. So you use a "type safe" language to do it. Compile. Commit. What? You never actually run the query? You're QA never runs the query?
You're worried that someone will put a string into a date query? Ever heard of parametrized queries?
Queries are a run time operation. Compile time safety buys you nothing except bad coding practices and a false sense of security.
Been doing this with GORM/Hibernate for awhile; all my HQL queries are checked prior to compile and throw errors if the types don't match. This really is nothing new or extraordinary... at least for Java devs.
This is good news. In related news, the recently released Opa also provides compile-time type safety for the DB, but it goes even further by providing type safety for the whole web application.
...Well, there's a namespace collision. There's slash and dot as referenced in the site's name, and / and . as in the characters commonly used in URLs. There's no way that wasn't intentional, and whoever's brilliant idea it was needs to be shot.
FTFY