| Author |
Message
|
| dogorsy |
 Posted: Tue Aug 06, 2013 6:04 am Post subject: |
 |
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
| kash3338 wrote: |
| dogorsy wrote: |
| Sorry, I think you misunderstood my post, I was talking about implementing ESQL SELECT ORDER BY, I said for ESQL SELECT from database it would be easy to implement, just syntax check and pass it to the database, I never mentioned PASSTHRU. |
The above point is not so clear.
You mean ESQL SELECT ORDER BY? There is no ORDER BY in ESQL, you need PASSTHRU to implement one.
The point made by smdavies99 is that to implement ORDER BY in ESQL, you need to use PASSTHRU and that is not used ta many places. |
Please read the post BEFORE making comments.
1- I know there is no ORDER BY in ESQL, that is why I said : "I was talking about IMPLEMENTING esql select order by". Implementing can be found in the Oxford English dictionary if not understood.
2- you do not need to use PASSTHRU to implement ESQL SELECT ORDER BY. again, look at the meaning of IMPLEMENT.
if you had followed the thread properly, you would have noticed we were talking about asking for an improvement to ESQL SELECT , and IMPLEMENT refers to an extension of the current functionality, i.e. improve the current select to allow ORDER BY. |
|
| Back to top |
|
 |
| kash3338 |
| Posted: Tue Aug 06, 2013 6:16 am Post subject: |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
My first point was,
| kash3338 wrote: |
| The above point is not so clear |
It could have been clarified in many gentle ways. But you chose this way,
| dogorsy wrote: |
| Please read the post BEFORE making comments. |
|
|
| Back to top |
|
|
| dogorsy |
| Posted: Tue Aug 06, 2013 6:22 am Post subject: |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
| kash3338 wrote: |
My first point was,
| kash3338 wrote: |
| The above point is not so clear |
It could have been clarified in many gentle ways. But you chose this way,
| dogorsy wrote: |
| Please read the post BEFORE making comments. |
|
and my point was that you need to read and understand the thread before making comments. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Aug 06, 2013 7:11 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mqsiuser wrote: |
| mqjeff wrote: |
| It's easy enough to write an insertion sort in ESQL to build the output tree |
I don't understand when people suggest alternatives to something that has been thoroughly discussed before. To properly implement ESQL-Sorting: Its not trivial (to consider all constraints) and best of all... it has been done before. If you found something (much) better post the relevant parts (of your insertion-sort algorithm) so we can review it.
And XSLT-Sorting can lead to memory consumption problems (as stated in one of the threads in this forum).
And ofc. if you can be wasteful with resources you can do so. |
An insertion sort is more natural to the nature of Broker message trees, and can be written in an easy way to avoid using extra space at the expense of extra time.
While I have always applauded your implementation of quicksort, I've never bothered to use it, because I've done as much as possible to avoid sorting records in ESQL in the first place.
Given that ESQL provides a lovely mechanism (the {}) to do a hash sort, where I've had to do sorting in ESQL, I've tended to hash sort records into smaller groups first, and then do an insertion sort on each group.
Given that I also don't tend to be responsible for the code I write over a long period of time, I try to make it as small and simple and straight forward as I possibly can, so that whoever has to pick it up after me doesn't have to struggle to figure out what that long complicated module does.
I also distrust things that do a lot of detach/attach of message tree nodes, as it's easy to leave some dangling.
I'd also have to fully test any code I included from somewhere else, as part of meeting the requirements of the business function being implemented. So stealing code doesn't necessarily save me a large amount of effort.
But this is all just my own personal opinion, without any meaning in the larger sense of things. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Tue Aug 06, 2013 8:39 am Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| mqjeff wrote: |
| An insertion sort is more natural to the nature of Broker message trees, and can be written in an easy way to avoid using extra space at the expense of extra time. |
Just to let you know. Quicksort also uses "no extra space" (though this wasn't like that in the beginning).
I think it is an upshot of ESQL to allow to "implement what you want/need" and not provide higher-level functions ((probably) even for something like sort (and GROUP BY)).
| mqjeff wrote: |
| While I have always applauded your implementation of quicksort, I've never bothered to use it, because I've done as much as possible to avoid sorting records in ESQL in the first place. |
I guess you are working a lot with (retrieving) data from databases and do PASSTHRU (as we all know from discussions in this thread by now  ) and ORDER BY... but actually...
The point that I wanted to go to... was that you may/might not need to "please" any target system with anything like sorting... sorting is not (so) important for systems integration?! It is handy for (human) traceability. My computer systems tend to not bother if data is sorted or not.
| mqjeff wrote: |
| Given that ESQL provides a lovely mechanism (the {}) to do a hash sort, where I've had to do sorting in ESQL, I've tended to hash sort records into smaller groups first, and then do an insertion sort on each group. |
The {} is magic in ESQL and perfectly suits requirements.
It is so straight forward and simple... and then... you implement complicated mappings with ease (with the help of it).
It sets ESQL apart from other languages
| mqjeff wrote: |
| Given that I also don't tend to be responsible for the code I write over a long period of time, I try to make it as small and simple and straight forward as I possibly can, so that whoever has to pick it up after me doesn't have to struggle to figure out what that long complicated module does. |
Hey... that is hitting on aggregate() and moveRef... and I admitted that. Quicksort is not a long complicated module!
| mqjeff wrote: |
| I also distrust things that do a lot of detach/attach of message tree nodes, as it's easy to leave some dangling. |
Probably not within a well tested procedure/function. (Tests are done by the community )... Thank you all for participating 
Though... I would have loved to not (need to) use DETACH/ATTACH... but I haven't found a way to remove it.
| mqjeff wrote: |
| I'd also have to fully test any code I included from somewhere else, as part of meeting the requirements of the business function being implemented. So stealing code doesn't necessarily save me a large amount of effort. |
That's why I posted it to the community, which should be able to find bugs within it.
No need for everyone to fully retest it. But anyway, that is a fair argument.
| mqjeff wrote: |
| But this is all just my own personal opinion, without any meaning in the larger sense of things. |
mqjeff's opinion is normative. No way to escape 
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Aug 06, 2013 9:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mqsiuser wrote: |
| mqjeff wrote: |
| Given that ESQL provides a lovely mechanism (the {}) to do a hash sort, where I've had to do sorting in ESQL, I've tended to hash sort records into smaller groups first, and then do an insertion sort on each group. |
The {} is magic in ESQL and perfectly suits requirements.
It is so straight forward and simple... and then... you implement complicated mappings with ease (with the help of it).
It sets ESQL apart from other languages |
I'm pretty sure they stole it from Perl. |
|
| Back to top |
|
|
| dogorsy |
| Posted: Tue Aug 06, 2013 9:18 am Post subject: |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
| mqjeff wrote: |
I'm pretty sure they stole it from Perl. |
Nope. Completely different usage. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Aug 06, 2013 9:46 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| dogorsy wrote: |
| mqjeff wrote: |
I'm pretty sure they stole it from Perl. |
Nope. Completely different usage. |
Nope, not really.
Sure, technically, there's a lot of difference under the covers. But a perl hash is just a single level tree with named nodes that hold values... and a hash of hashes is a multi-level tree with named nodes that hold values...
And the fact is that I can access a hash of hashes in Perl by saying
| Code: |
| myHash{'myKey1'}{'myKey2'} |
and can do the same thing, logically, like
| Code: |
| InputRoot.{'myKey1'}.{'myKey2'} |
|
|
| Back to top |
|
|
| dogorsy |
| Posted: Tue Aug 06, 2013 10:00 am Post subject: |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
[quote="mqjeff"]
| dogorsy wrote: |
| Code: |
| InputRoot.{'myKey1'}.{'myKey2'} |
|
sort of, but the code above is the same as ( I think )
| Code: |
| InputRoot.myKey1.myKey2 |
as 'myKey1' and 'myKey2' are character constants. And that is different to
| Code: |
| InputRoot.{myKey1}.{myKey2) |
where myKey1 and myKey2 are character variables, and the path gets resolved at run time to the value held in those variables. Maybe you meant that, but just clarifying.
You can also code
| Code: |
| InputRoot.{"myKey1"}.{"myKey2") |
in case the variables myKey1 and myKey2 contain special characters |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Aug 06, 2013 10:09 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
So, what you're saying is, I used the wrong quotes, but you still understood my point?
Good deal.
It's still not a completely different usage...
perl uses { } to indicate a name to use as a lookup on the name of a specific node in a single layered set of named nodes.
ESQL uses { } to indicate a name to use as a lookup on the name of a specific node in a single layered set of named nodes....
Whether or not MGK actually stole this from Perl when he decided to implement {} in ESQL is a separate question. I'll leave it to people sitting closer to him to decide if it's worth bothering him to find out. |
|
| Back to top |
|
|
| dogorsy |
| Posted: Tue Aug 06, 2013 10:24 am Post subject: |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
| mqjeff wrote: |
So, what you're saying is, I used the wrong quotes, but you still understood my point?
Good deal.
|
Sorry, I was not being pedantic. Just clarifying as I know people are going to start trying and then saying it does not work ! |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Tue Aug 06, 2013 12:13 pm Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
Though {} is really great, I argue to use MOVE ref WHERE for doing GROUP BY
Nobody picked up on this yet:
| mqsiuser wrote: |
| I think it is an upshot of ESQL to allow to "implement what you want/need" and not provide higher-level functions ((probably) even for something like sort (and GROUP BY)). |
GROUP BY is done by {} or ... better ... MOVE ref WHERE
| mqsiuser wrote: |
| mqjeff wrote: |
| [...] I've never bothered to use it, because I've done as much as possible to avoid sorting records in ESQL in the first place. |
[...]The point that I wanted to go to... was that you may/might not need to "please" any target system with anything like sorting... sorting is not (so) important for systems integration?! It is handy for (human) traceability. My computer systems tend to not bother if data is sorted or not. |
GROUP BY is highly relevant to please target systems (but there is no (great) need for a GROUP BY clause in ESQL SELECT).
ORDER BY is not so relevant (to please target systems), but for (human) traceability and special cases (that (may) occur).
ESQL-SELECT will create an output-tree based on an input-tree (if applied on one). But sorting should (likely) just happen in place (with no additional mem-consumption).
So an ESQL-SORT-Function will/would be the right approach. Since there is none native (probably with reason), this can be caught up in a layer above (in ESQL itself).
All seen from my world's point of view
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
|
|
