rearranging the statement structure

[Dustin]

We've talked a bit about allowing the FROM clause to introduce the
query. I'm curious to hear the opinions of others here.


Justification:

There are two justifications that I've heard:

The first is really just aligning it with the thinking process
better. You begin with the entire universe of data. Then you add
``FROM articles'' to limit the query to just that collection. Then
you add a WHERE clause to find matching documents within that
collection. Finally, you add a SELECT clause to describe what comes
out of that process. The mental model falls in line very well with
functional programming tools (see LINQ and Ambition for places where
it's possible to swap an array out with a database without changing
any code).

The second is a pragmatic, but not immediately useful one -- it
makes easier to have tools assist you more quickly by knowing what
you're looking at right away. Starting with select you're really
describing the final phase of output after having gone through the
exercise of describing what you want.


It's a fairly small thing, but I'd be interested to hear if anyone
has any strong feelings either way.

[p...@pi.net]

> It's a fairly small thing, but I'd be interested to hear if anyone
> has any strong feelings either way.

I'm not quite sure I understand the proposal. It reads like you are
proposing an alternate syntax next to the currently proposed syntax,
or are you proposing to make the alternative syntax the only syntax?

Also, I'm not quite sure what the new syntax would be in the proposal.
Does SELECT now come at the very end, also after e.g. ORDER BY and
OFFSET/LIMIT? How does it sit with the compounding operators (UNION,
etc. -- perhaps more problematic in SQL than in UnQL)?

The 'processing pipeline' idea has a certain beauty to it. How would
it work if e.g. the FROM clause is left out? Would that imply an outer
join of all available collections?

Paul

[Dustin]

On Friday, August 26, 2011 2:44:05 AM UTC-7, p...@pi.net wrote:

 

I'm not quite sure I understand the proposal. It reads like you are
proposing an alternate syntax next to the currently proposed syntax,
or are you proposing to make the alternative syntax the only syntax?

  I was leaving it slightly ambiguous to see what opinions arose.  :)

  I like the idea of moving it to the front.  In discussion, Richard suggested it might be nice to let the user put it wherever is most convenient.

 

Also, I'm not quite sure what the new syntax would be in the proposal.
Does SELECT now come at the very end, also after e.g. ORDER BY and
OFFSET/LIMIT? How does it sit with the compounding operators (UNION,
etc. -- perhaps more problematic in SQL than in UnQL)?

  Yes, that's the idea.  FROM says where to start looking, and SELECT presents the results.

  I haven't put too much thought into things like UNION, but I would perhaps expect that to be even higher order since you're really specifying the concatenation of two queries.

  FROM collection_a

     WHERE color = 'blue'

     SELECT widget

  UNION ALL

  FROM collection_b

    WHERE color = 'blue'

    SELECT widget

  Does that make sense?

 

The 'processing pipeline' idea has a certain beauty to it. How would
it work if e.g. the FROM clause is left out? Would that imply an outer
join of all available collections?

  I'm actually not concerned about document queries that don't specify document collections.  IMO, we're trying to make it easier for people to get to their documents.  It doesn't seem unreasonable to require them to start with which documents they want to dig through.

[Dan Kennedy]

Seems to me it's more logical to put the SELECT clause at the end
of a statement.

But given how widespread SQL is, and how obviously UNQL is based on
it, changing it will make UNQL less intuitive to the masses. Will
the UNQL SELECT statement be referred to as the FROM statement
instead? Or as "the statement similar to the SQL SELECT statement"?

It's only a fraction of SQL users that have even noticed that the
order of the other clauses in a SELECT statement makes sense anyway.

Dan.

[James Phillips - Personal]

While it is nice to be SQL-like, I believe one of the reasons many are moving to competing solutions is, in part, due to some of the perceived unnecessary complexity in SQL. I think we have fundamentally missed the mark if we try to shoehorn SQL as a language into the world of document-oriented database solutions versus recognizing that there are differences ... and an opportunity to leave behind some of the irregularities of the past.

And I completely disagree that making this change will make UnQL less intuitive to the masses. Perhaps the old school SQL crowd...but that is not the masses by any measure. We are trying to build something for the masses of application developers that are beginning to reject reject SQL as a tool for interacting with non-relational data. See the "success" of ORM tools and related layers of software designed to hide the language from "the masses." That is where the masses live and work today.

Perhaps we need to step back and ask why we are building UnQL. What are the goals and what design criteria do they imply? Keeping that which is illogical and cumbersome to avoid relearning for a few seems incredibly wrong. But, again, depends on your goals.

James Phillips
408-832-3066 (cell)

[Hans Marggraff]

I would very much like to see this proposal realized.
The counterintuitive order of SQL statements has already been
critisized in the 70ies, just after SWL came out.

If unql seriously strives to be a next-generation query language, then
it should do away with the old silly order.

The pipelining process, that is possible with the changed sequence is
"a small change" for the implementation, but it opens a door to many
new possibilities.

It takes out the guesswork of what actually goes on inside the query
procecssor.

With the proper statement order each statement takes some data
processes it and returns different data (or in a different form)

While "select field_x" in sql is useless
"from collection_x" is a complete query.
(equivalent to "select * from table_x", but much shorter.)

If even Microsoft had the courage to change that old mistake, then
unql should change it too.


On 27 Aug., 12:38, James Phillips - Personal

<jamesmalcolmphill...@gmail.com> wrote:
> While it is nice to be SQL-like, I believe one of the reasons many are moving to competing solutions is, in part, due to some of the perceived unnecessary complexity in SQL. I think we have fundamentally missed the mark if we try to shoehorn SQL as a language into the world of document-oriented database solutions versus recognizing that there are differences ... and an opportunity to leave behind some of the irregularities of the past.
>
> And I completely disagree that making this change will make UnQL less intuitive to the masses. Perhaps the old school SQL crowd...but that is not the masses by any measure. We are trying to build something for the masses of application developers that are beginning to reject reject SQL as a tool for interacting with non-relational data. See the "success" of ORM tools and related layers of software designed to hide the language from "the masses." That is where the masses live and work today.
>
> Perhaps we need to step back and ask why we are building UnQL. What are the goals and what design criteria do they imply? Keeping that which is illogical and cumbersome to avoid relearning for a few seems incredibly wrong. But, again, depends on your goals.
>
> James Phillips
> 408-832-3066 (cell)
>

[Dustin]

On Monday, August 29, 2011 7:01:19 AM UTC-7, Hans Marggraff wrote:

 

While "select field_x" in sql is useless

  In SQL, you can do "select 'literal' " or "select function() " or similar, but I'd rather see something like "from __literals__ select 'literal' " for the cases where someone needs something like that.  If the purpose is to define a way to get things out of the database, it seems to me that the language doesn't need to be optimized to get things that aren't in the database.  I recall Oracle enforcing something like that last time I used it.

 

"from collection_x" is a complete query.
(equivalent to "select * from table_x", but much shorter.)

  I do like this as well, but it brings up another interesting bit from LINQ -- the output of the FROM clause has a name.

  I think that makes a lot of sense when you have something that is a collection that has an item and you're filtering on effectively each item, but the default is to confusingly express the filter against the collection as a whole:

    from collection_x where collection_x.field_name = 'blah'

  vs. LINQ's

    from x in collection_x where x.field_name = 'blah'

  The former is certainly usable, but the latter reads pretty well like a foreach loop, which I think is a great way to think about it and fits well within application code that is intending to access documents.