Type Safety Coming To DB Queries 128
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."
Gibberish - wrapped up as geekspeak (Score:4, Insightful)
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.
Re: (Score:1, Flamebait)
If you're on Slashdot, you shouldn't need a link to tell you what Rogue-like [wikipedia.org] means.
Re:Gibberish - wrapped up as geekspeak (Score:5, Funny)
The server hits you with its internal schema!
You cast SELECT * FROM ut_f81 INNER JOIN ut_f81 alt_ut_f81 ON alt_ut_f81.globalid = ut_f81.rrn / 2 WHERE (SELECT * FROM ut_f81 INNER JOIN ut_f81 alt_ut_f812 ON alt_ut_f812.globalid = alt_ut_f81.rrn / 2 WHERE (SELECT * FROM ut_f81 INNER JOIN ut_f81 alt_ut_f813 ON alt_ut_f813.globalid = ut_f81.rrn / 2 WHERE (SELECT 1 FROM ut_f81) = 1) = 1) = 1
The server freezes, taking all of your work with it!
Do you want your possessions identified?
Re: (Score:2)
Wait guys. Someone named "Samantha" just made an awesome SQL + Nethack joke and no one here has proposed to her yet. What the hell is Slashdot coming to?
Samantha Wright, will you marry me?
Re:Gibberish - wrapped up as geekspeak (Score:4, Interesting)
That's probably because everyone else on the entire internet has already proposed. I think it's bad luck to try the same pickup line twice on the same woman.
...while it's flattering, I don't think my girlfriend would be too happy.
Re: (Score:2)
Re: (Score:3)
Maybe we all know better than to marry a woman who can compose such Lovecraftian monstrosities in the guise of SQL queries. ;)
Re: (Score:2)
Re: (Score:3)
I know what the rogue game is, and I know what rogue-like games are. I am utterly and completely baffled how this applies to databases and the link was not informative (it was the opposite of informative because now I think I know even less than I did before I tried to read it).
Re: (Score:2)
"Rogue is a type-safe internal Scala DSL for constructing and executing find and modify commands against MongoDB in the Lift web framework."
First line in the readme.
If you don't understand that, and can't use that page and Google to help you understand, then you need to move on to the next article. Your comment is pointless. Learn how to research things for yourself.
It would be like me seeing a summary article about gravity waves, and clicking a link to the Wikipedia entry on general relativity, and compl
Re: (Score:2)
Wikipedia would tell you what gravity waves are. The links did not tell anything about rogue-like. Besides 99.95% of slashdot knows that rogue-like refers to games. So we're all going to look at this and think about games and try to read further instead of moving on.
Re: (Score:2)
The Rogue [github.com] link in the summary explains EXACTLY what Rogue is. It is a domain specific language for database commands.
Are you seriously getting this worked up over using the term "Rogue-like" instead of "similar to Rogue"? Do I get worked up over Slashdot articles that say Microsoft is a monopoly, simply because there is a popular game called "Monopoly" I like to play?
Give me a break.
Re: (Score:2)
And here I was expecting Slash'em and Rouge-like to refer to the text based dungeon explorer games......so get off my digital lawn.
Re: (Score:3)
Roguelike was a joke I think, and probably shouldnt have been added to the submission.
Not being either a programmer or a database admin, I still think I grasped the point-- that there is a new language out for database queries which prevent you from making invalid database queries because of wrong types (string vs binary).
I dont think it was awful as submissions go, but I suppose they could have clarified what a database is, what type-safe is, and what a query is.
Re: (Score:1)
To be fair, the title of the story was 'Type Safety Coming To DB Queries.' If you don't know what four of those six words mean, then it probably isn't for you.
Re: (Score:3)
This is not gibberish by any stretch. I understood every bit of the summary upon first read (while jet-lagged and half-asleep) found the links directed me to the follow-up info I would want. and with my only point of reference being that I happen to have a basic understanding of what Solr is (ie. search engine, in java).
Consider that: /. story needs to be relevant and comprehensible to you. /. use
a) not every
b) summaries don't need to be book length and include an intro to computer science.
Re: (Score:1)
Oh well... if you could understand it half-asleep and jet-lagged... it must be ok.
People like you are the reason normal people hate IT. If you can look at that article submission and think "that's fine as it is" and write the post you just did without a trace of irony ... then you are an immature socially retarded halfwit.
Clue: "highly technical"l doesn't mean an in-depth knowledge of every bit of web 2.0/nosql bullshit with ironic names that only about 3 people (including its creator) give a shit about.
Re: (Score:2)
Re: (Score:2)
Nobody is assumed to have knowledge about "every bit of web bullshit".
Well actually, the author of the submission did.
No-one is talking about an encyclopedia entry - just a bit of context for those of us who don't spend our time fetishising the latest nosql data bucket with holes in it.
Re: (Score:2)
This is /.
"Normal people" don't belong here.
No prereq knowledge is required to comprehend the summary.
I see you didn't bother to come up with a better one, as I suggested.
Re: (Score:2)
maybe there was a type mis-match in your query.
Re: (Score:2)
You call us F*ing stupid, but yet you're the only one that had difficulty figuring it out...
- Dan.
Re: (Score:2)
Re: (Score:2)
You're the one who can't read, therefore I'm stupid.
Makes sense.
If you're a moron.
Re: (Score:2)
You're so scared of us, you've gone coward.
Be afraid, be more afraid.
Slashem, a roguelike (Score:5, Insightful)
Re: (Score:2)
I'm personally of the opinion that the only way they could make me trust anything they've ever touched with data, less, would be to call it "Willloseyourdata" or similar. This makes GIMP look like a masterpiece of software naming.
Confusing much? (Score:4, Informative)
http://en.wikipedia.org/wiki/Roguelike [wikipedia.org]
Rogue-like has already been used. It's very confusing to say your DB query language is like a video game.
Re: (Score:3, Informative)
Worse, Slash'EM [slashem.org] is already the name of a (real) rogue-like (game). Obviously these guys are trying for a witty or clever play on "rogue-like" and "slashem", but it just comes off as confusing and lame.
Re: (Score:2)
Great more training wheels (Score:2)
Re: (Score:1)
Re: (Score:1)
Only if they can find a way to do such without bloating up the code with verbose declarations.
Re: (Score:1)
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.)
LINQ (Score:5, Interesting)
The title is incorrect; type safety is already available in DB queries, at least on Windows clients. You can use LINQ [wikipedia.org] directly in C# and VB, or standalone via LINQPad [linqpad.net].
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).
Re:LINQ (Score:4, Interesting)
The difference between this and LINQ is that LINQ is more or less hardwired. Sure, it is just syntactic sugar for a bunch of method calls, and those methods can do anything they want, so there are many extensibility points; but you cannot add a new LINQ keyword from a C# library, for example - you're stuck with "select", "join", "orderby" etc.
This one, on the other hand, only uses existing Scala constructs, with no need to alter the language itself.
But, yeah, I wouldn't call it such a big difference in practice, so it's certainly not a first.
Re: (Score:1)
Re: (Score:2)
You are most certainly not stuck (unless you're using query syntax, instead of method syntax) because all LINQ methods are just extension methods. A LINQ provider could easily add new ones.
Re: (Score:2)
unless you're using query syntax, instead of method syntax
That was specifically what I was referring to when I said "keywords". Sure, you can add your own methods, but it's not really LINQ (Language INtegrated Query) then, isn't it? It's just a method that takes an expression tree.
Scala is rather more flexible with regard to syntax, specifically so as to enable expressive DSLs, so there's no real need for a hardcoded set of keywords for sequence comprehensions like LINQ.
WTH? (Score:5, Funny)
I think that description might have been CleverBot making an attempt on the Turing Test. What the hell?
Re: (Score:2)
I'm beginning to suspect there's a serious flaw in the Turing test, and it's humanity.
Re: (Score:2)
Reinventing the wheel (Score:2, Insightful)
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).
Re: (Score:2)
Interesting. What is your opinion on embedded SQL? (as i Pro*C/C++ or equivalent)?
I never completely understood most of my colleagues' preference for JDBC-like access to a database, when embedded SQL catches most errors much earlier (t compile-time). Sure, it is kind of ugly, but JDBC-like access with its many getString()/getNumber()/... isn't pretty either.
Re: (Score:3)
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).
How would you do it in C++? Are you proposing a pure library solution (which I can't quite comprehend how you intend to implement), or a preprocessor?
Re: (Score:3)
C++ supports domain-specific embedded languages, which blur the distinction between libraries and compilers.
DSELs in C++ are implemented through expression templates, Boost.Proto formalizes the way to define grammars and tree transformations for such things.
Re: (Score:2)
I don't see how you could possibly implement "SQL itself" as a DSL in C++ templates. Boost.proto or not, your syntax options are still constrained by what C++ has to offer.
Re: (Score:2)
Of course, it must be valid C++ syntax. But that's hardly a serious limitation.
select >> "*" >> from >> "t" >> where >> "foo" == "bar"
is a possible syntax. You could also use '.', '[]', or whatever you think is nice.
Re: (Score:2)
Re:Reinventing the wheel (Score:4, Informative)
Solr serves a different purpose to SQL. It is optimised for searching using text indexing with fancy ways of matching, weighting results when finding matches. Solr is actually a separate non-SQL database that you keep in sync with your real database. I've found it fits its purpose very well, and you rarely worry about the XML as library support handles it.
SQL is great if you already know exactly what you're looking for. Solr is great if a human is performing a search.
Re: (Score:2)
Parameterized queries require pre-registration with the database engine, and have a host of other gotchas. EG: No dynamically created SQL queries.
Remembering to escape every variable also has it's own gotchas, including the inevitable security hole when you mistook public data as trusted source data.
So we rolled our own variation of parameterized queries, that includes references to the table/field in question so that type analysis can be done on input prior to parsing the query statement. It's highly effec
Re: (Score:3)
Parameterized queries require pre-registration with the database engine, and have a host of other gotchas. EG: No dynamically created SQL queries.
No. That's just your sucky database client library. OTOH, if you've got a parameterized query then you absolutely should be able to cache it so that you can reuse it, avoiding a recompile of the query where not necessary. Some client libs can handle that for you automatically, others are more intrusive. (Some languages even have wrapping layers available that make nasty low level libs much more palatable.)
That the language is SQL or something else, that's wholly independent really.
Remembering to escape every variable also has it's own gotchas, including the inevitable security hole when you mistook public data as trusted source data.
Now that is very true. If
Re: (Score:2)
Parameterized queries require pre-registration with the database engine, and have a host of other gotchas. EG: No dynamically created SQL queries.
This is a feature, not a bug.
Build all your queries as parameterized queries (or better yet, stored procedures) and you will never have "type safety" problems. In fact the posting barely makes sense to me. How would you ever end up trying to date-range a string field? That query would never run! Oh right, there are still idiots out there that build queries at runtime. Well, don't fucking do that!
Besides, parameterized queries are 100% immune to SQL injection. You'd think people would care more about t
I like these training wheels (Score:2)
Because as someone who writes SQL queries all day long and thinks this is silly, I now have a reason to feel superior. :-)
Re: (Score:2)
as someone who writes SQL queries all day long
Cool. Maybe you can help me with something. I have a table (time_stamp | direction | bytes). I use the data to draw two lines. An out line and an in line. Each point of the line is a sum of bytes over 10 seconds for a range of time. Is there a way to return a series of sums without using code to decrement variables and run a query for each sum? ie. return a sum per 10 seconds over 60 seconds. Or basically, replace the code below.
int start_time=-60, end_t
Re: (Score:2)
select x.start_time
, p.direction
, sum(p.bytes) as b
from (select -60+10*(level-1) as start_time
from dual
connect by level <= 6
) x
, packets p
where p.time_stamp >= x.start_time
and p.time_stamp < x.s
Re: (Score:2)
Very nice. Thank you!
Dumbing it down (Score:1)
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 obvio
Re: (Score:3)
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
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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 tha
Re: (Score:2)
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 exceptio
Re:Dumbing it down (Score:4, Insightful)
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 [wikipedia.org] like Hibernate [wikipedia.org], 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.
Re: (Score:2)
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?
Re: (Score:2)
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
Re: (Score:2)
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 l
Re: (Score:1)
Re: (Score:3)
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 th
Re: (Score:2)
How I wish I had your faith in the average DBA.
Re: (Score:2)
How your average DBA wished they had any faith in the piss pore excuse for programmers they see these days.
Re: (Score:2)
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.
the more xml (Score:1)
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 mul
Re: (Score:2)
XML, the answer to the question nobody asked.
Re: (Score:1)
solution in search of a problem (Score:1)
Type errors in Solr queries don't strike me as a burning problem.
And why does... (Score:3)
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.
LINQ (Score:1)
Re: (Score:2)
I really miss LINQ (especially LINQ-to-objects) when I write in other languages.
How about content safety, instead... (Score:1)
I don't understand... (Score:5, Funny)
How will getting the Amulet of Yendor get me type safety?
Databases are already strongly typed (Score:2)
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.
type-safe binding to PostgreSQL for OCaml (Score:1)
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."
Re: (Score:2)
Bingo. Exactly what I have been saying for years, but... we both know that this sort of idea is far too sensible and boring for the 'concept du jour' programming community.
Already been done!!! (Score:1)
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 [haskell.org] has had its own database query library for years now, which works with
Catch on? Like this? (Score:2)
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...
Type safety schizofrenia (Score:1)
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!
Yeah, hope this catches on (Score:1)
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?
Don't use MySQL (Score:2)
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?
Pointless (Score:2)
Solution looking for a problem (Score:1)
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.
Re: (Score:2)
You're worried that someone will put a string into a date query?
Exactly. Compile time safety is worthless if your db app allows 'somebody' to put something into a field. The only way this (compile time) will buy you anything is if you can restrict all access to records to prevent wrong types from sneaking in. And this includes the administrative CLI that someone could use to manually poke garbage in.
Run time safe apps need to handle type mismatches gracefully. A string where a date is expected in a query can be handled in a number of ways, depending on the needs of the
Re: (Score:1)
Re: (Score:2)
I don't think so. In the above example, the field in question is type string, but the app expects a date. Or its such a crappy db that its possible for some app to shove a string into a date field without throwing an exception. Neither of these cases involve dynamic typing. But both need run time checking.
Dynamic typing (to me) means that I should expect any possible type in each field and be able to deal with each one. All I'm saying is that an app needs to be able to handle two cases: the expected type
Re: (Score:1)
Type safety for DB is great (Score:1)