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.
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.
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.
There are a couple of problems with this:
1. Everybody thinks they're the highest performers. You have to be smart enough to know when you're being dumb, and most of the dumb performers aren't smart enough to realize it.
2. You assume there's a good reason for doing things a certain way, and that reason hasn't been invalidated. Programmers used COBOL, FORTRAN, and Assembly for a good reason, and now very few programmers use them, for smaller good reasons. This is a move to a higher level language. People did raw pointer math in C, in part because it was fast and in part because there wasn't a better way to do it. Now we have higher-level languages that handle that material, and they are slower to run, but much faster to code.
The basic fact about higher level, more insulated languages is that programmer time is much more expensive than computer time, and programmer mistakes are even more expensive. The narrowing opportunity that this produces means less ability for high-performance, hacky, unmaintainable code that no one else is smart enough to understand, but much more opportunity for building powerful applications. The explosive growth of web apps is directly tied to the power of the languages they're built on.
I know nothing about this particular implementation, but the concept of protecting the programmer from himself is actually a sound one, and I think you need to avoid being so defensive about it.
Remember, there were no nuclear weapons before women were allowed to vote.
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.
A proper implementation of something like this wouldn't prevent you from doing a range query on the string field - it would, however, require that you write an explicit cast from string to date before you can apply date operators to it. The output SQL might not have anything corresponding to such a cast if it's not needed; its whole point is to indicate that you really know what you're doing to the type checker.
Static typing is almost always a good thing in big projects, and database queries are no exception.
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.
This appears to be more of the 'nanny state' mentality that Microsoft is shoving down our throats.
Sheesh... I was going to moderate a few items in this thread, but I just have to reply to your ignorant excuse to bash M$ --like they invented type-safety.
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.
Really? Technologies that help minimize errors through convention are a bad thing? So if you're in a shop that saves countless hours of time and debugging using a modern ORM like Hibernate, that makes you some sort of slack-jawed moron because "real" programmers do everything in assembly and don't need no stinkin' oversight, static code analysis, testing, or code review, right? Sheesh... Remind me not to hire you to code any systems where human safety is on the line. Most employers --even for inconsequential crap-- would rather have working apps than theoretically pure code; they can buy another rack of servers for what a good developer earns, so in most cases they really don't give a damn about efficient code.
Besides, even if you think type-safety = training wheels, if you've been coding long enough, you'll see idiots and geniuses get slapped by typos and inadvertent mistakes. Only an amateur thinks they're immune to error and that things like type-safety just cramp your style. And real programmers can go around these things off when they need to, but take advantage of lower bug counts the rest of the time.
Ask me about my sig!
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?
You're so scared of us, you've gone coward.
Be afraid, be more afraid.
How I wish I had your faith in the average DBA.
"Early Testing"? It should be caught while typing it or at least while proofreading it. Shitty code should not even make it to the "run" stage.
Only if they can find a way to do such without bloating up the code with verbose declarations.
Table-ized A.I.
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.
People did raw pointer math in C, in part because it was fast and in part because there wasn't a better way to do it.
I disagree, I think they did it because they were suffering from NIH and refused to select a library that did hid that nonsense in a safe place.
No idiot, they did pointer match because it was blindingly fast and it had nothing to do with NIH, it had to do with good solid programming using the machine as efficiently as possible. I they build "web languages" that way today fucking /. it would not take for fucking ever and a rack full of servers ,to do anything.
Hey KID! Yeah you, get the fuck off my lawn!
You'll see idiots and geniuses get slapped by typos and inadvertent mistakes
And you think this bit of crap will prevent that? Sheeeesh are you really that naive?
Hey KID! Yeah you, get the fuck off my lawn!
How your average DBA wished they had any faith in the piss pore excuse for programmers they see these days.
Hey KID! Yeah you, get the fuck off my lawn!
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."
That is the thing. More modern programming languages aren't easier - they've just got more clear-text primitives and fewer possibilities. But possibilities are just confusing (it is reasoned), and more typing is caught by using auto-completion on eclipse.
Religion is what happens when nature strikes and groupthink goes wrong.
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
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?
The problem with these 'higher' programming languages is that they are the house built upon the sand.
The folks that build the microprocessors have everyone else by the balls, and we don't even know it.
Introduce true multi-core processors, and where is your VB? Where is your Python? Your Java? Your Eclipse?
Introduce Quantum computing, and all the high level languages need to be thrown out because they will be incapable of expressing a functional solution to a problem on these new platforms.
All that this is doing is breeding a generation of programmers who are too lazy to manage their typecasting properly because the auto-completion does it for them.
To me, this is about the distinction between 'business programming' and 'computer science'. In business, you want your development platform to compensate for the McDonald's grade programmers you hire (because they're cheap). In science, you want freedom to innovate and explore.
This technology has its place, and it is at the boring end of the spectrum.
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.
You'll see idiots and geniuses get slapped by typos and inadvertent mistakes
And you think this bit of crap will prevent that? Sheeeesh are you really that naive?
Clearly you're right. There is no amount of idiot-proofing that can't be overcome by a determined idiot, so having tools/languages/methodologies that help prevent errors is just a horrible idea. Type-safety, enumerations, compiled code, etc. are really bad ideas that add nothing to the quality of our code. We should all be using scripting languages programmed on punch cards so our code will be the bestest evar. Avoidable run-time errors like type mismatches that crash production systems are a good thing --don't you love surprises?
Ask me about my sig!
Unless your working with sqlite3 where the date field is a string. Being forced to use date or datetime to examine the text field so the engine compares entries with the correct string format isn't much different from this approach.
Having to work for a living is the root of all evil.
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.
So far I haven't seen a way to do such without verbose type or language constructs. They make code more bureaucratic in my experience. Bureaucratic code can be harder to read and maintain in many situations.
(I posted a similar response before, but for some reason it got "lost". My apologies if this is a dupe.)
Table-ized A.I.
Nope I sure don't, but I also do not like having to include 500 megs of code to be able to do anything.
Is there no fucking end to this "nanny state and let's put rubber baby buggy bumpers and fucking everything" just so some god damn fucking moron can play at being a programmer?
The world has sharp corners how about having an attention span great then that of gnat and pay attention to what you are doing? Now there's a novel concept!
But oh no, lets take a perfectly serviceable, and quite excellent language like SQL and wrap it in 500 megs of dumb down code so that idiots can play at being a programmer. How many people bitch on moan about the Linux kernel not being written in a language that is all warm and fuzzy so that joe sixpack can write drivers for it without knowing a thing about hardware and memory allocation and utilization?
Hey KID! Yeah you, get the fuck off my lawn!
The type safety is compile time. After compilation, it's as if it doesn't exist. Oh, and Glasgow Haskell and Gambit-C Scheme would like to have a word with you. Right after Ada, Eiffel and Modula-3 are done with you.
I know tobacco is bad for you, so I smoke weed with crack.
Nope I sure don't, but I also do not like having to include 500 megs of code to be able to do anything.
Look... If you're writing high-performance device drivers, cutting edge physics simulation engines, or the like, my hat's off to you --that's serious code where every cycle counts. For the other 99.9% of us, ruthless efficiency isn't our highest priority anymore; we are being paid to be productive and not screw up. If a complex app takes one hour to debug rather than one month, I have more time and money. Smart people use productivity tools to their advantage.
Is there no fucking end to this "nanny state and let's put rubber baby buggy bumpers and fucking everything" just so some god damn fucking moron can play at being a programmer?
Admittedly things like M$ VB have lowered the bar and many employers don't know good developers from bad, but saying that easier to use technologies are bad is Luddite thinking along the lines of saying that people being able to place their own phone calls or take their own photos is somehow a bad thing. Besides, if you don't like the safeguards on newer systems, nobody is preventing you from continuing to write everything in assembly, COBOL, or binary if you like.
The world has sharp corners how about having an attention span great then that of gnat and pay attention to what you are doing?
"attention span great then that of gnat"?
Wow, look at that. If this were code, you'd have three errors in under six words --and there's more nitpicking material where that came from. I'm guessing that without a spell checker (another one of those damned, meddling, nanny state things!) you might have made even more errors. Back in the good old days when I wrote code in scripting languages, simple mistakes often wouldn't be caught until a user hit a particular piece of code. I much prefer finding obvious problems at compilation --or not even making those mistakes thanks to things like code auto-completion (or training wheels, as you might say). My tools aren't dumbed-down, they're smart enough that I can worry about the big ideas instead of investing mental energy in double-checking my data types and other distractions.
Ask me about my sig!