Version 9 - How do I view SQL with the Aggregates?

Version 9 - How do I view SQL with the Aggregates?

The Aggregates in 9 are slow and takes up the entire screen.  You can't see the Sources and Filters at the same time.  Who thought this was a good idea?  Worst thing is that I can't see the generated SQL.  Why is this not visible? Huge step backwards unless I'm missing something.
Hello David,
Thanks for the honest feedback on the new Aggregates. Let me try and address each issue in turn:
1. Aggregates use the entire screen so that you can view as much data as possible. Aggregates are all about working directly with data, so that you get instant feedback on what you do - ultimately making the whole development loop faster;
2. Having said that, aggregates shouldn't be slow. If you could share with us which parts you believe are slow or indicate a particular case where things haven't been as responsive as they should, that would be of extreme value to us;
3. About the sources being visible while editing the filters, could you give us your view on why you believe that is important? For the top usage scenarios we considered, that information wasn't necessary, but we're always eager to learn about the different ways developers use our platform;
4. The generated SQL will be available soon. We'll release it in one of the upcoming patches to 9.
We truly believe that this new way of manipulating data is the way forward. It's kind of like the difference between having to do "circle(0,10,10)" and run to see the result, versus drawing a circle directly on the screen. 
But we understand that this is a big change that will require effort to learn and get used to. We also know that we'll need to make adjustments, now that this new feature is on the field.
So, feel free to answer directly on this forum, but if you'd like to talk a bit about aggregates DM me your contacts and we can arrange a conversation. It would be very valuable to us.
Thanks again,
Thank you for the response Rodrigo. 

1. As is, it's not making me any faster.  Maybe when the SQL pieces are added, it will but right now, I wish I had access to the SQL wideget.  The window covers up my flow and hides it from me.  I personally don't like that.
2. The interface is sluggish; very similar to the add/remove references interface.  It seems to take me 2-3 clicks just to get the drop downs to work. 
3. I feel it's important to be because I like to see the whole picture.  Like 2 above, I like to see everything.
4. Great! I'll look forward to this.
I also look forward to having the SQL display feature back.

And I would really rather the aggrigates be windowed instead of in the main display, too... I keep having to go back to view my flow to figure out my missing pieces rather than just moving the window a bit.

The instant display of the data is fantastically useful, and the new interface is workable (I particularly like the join mechanics and the simplified inbound parameter passing), but the fact that it takes up my whole work environment and I have to go backwards and forward to find everything is a massive disappointment.
I haven't used it yet, but I can say that I depend on the current Query editor being in a window *all the time*. I'll have another one open so I can compare them, or copy/paste parameter or conditions between them, or go through the Entities looking for the right one, etc. etc. etc. As others have said, if I couldn't do that it would be a lot of extra work to edit a query.

I also think that having the SQL display would be nice.
Any feedback on the generated SQL display?
Hi Jaco,

The SQL display is currently in beta, together with some other improvements. It will be released by the end of February!

Hi all,

The aggregate queries, as a user, I think it has the following disadvantages:
- When we are doing debbug, does not show us all input variables values, as was in the past;
- Currently when we add an entity, does not automatically make the join, as was in the past;
- I think it should have a button to test the query, I think it's annoying (and sometimes causes crash service studio ) when we are introducing values, because it will always refreshing the resulting and if by chance there is a mistake gives error ...
- I also find important to have an overview of the joins with the filters and sorting, as had formerly;
- I also think very important to have access to SQL generated by the query to test.

Is my sincere contribution as user.



Hugo Castro
Good to hear this is coming.
For all those desperate to see the generated SQL just use your favourite traffic sniffer of choice... I like Fiddler.

Rodrigo Coutinho wrote:

Although I've complained a lot about in that other thread, I'll answer these questions here, as I think they're important and show a bit of insight into the minds of OS development.

1) I can maximize a window if I want to view as much as possible. Now you're taking away the choice for the user. Removing choice is always bad when dealing with a diverse community of partially expert users. And no, you don't get "instant feedback". You get feedback after waiting 30sec-1min is you're dealing with large tables. See also next point.

2) They are slow because after adding a table manually, there's no link yet, so Service Studio decides it's a good idea to do a cross join (iirc). Not good if you've got a table with a few million entries. Also, even after setting up the join, you may want to set some restrictions, but before you can do that, SS already decides to fetch all data (which is annoying, especially if you want to limit to some Id).

3) It is important, because the difference between a join and a filter is not that clear cut! In advanced query's we typically put the "filters" together with the joins in the ON part, especially if they're fixed filters (e.g. only records of a certain type). Crucially, when doing a LEFT JOIN, such filter can't be part of the filters, as you'll get no output if no record is found! The fact that OS "considered" some "top usage scenarios" and therefore made some design decision is extremely naive, as for any top scenario, there's hundreds of others. In our enterprise application, we litteraly have thousands of simple queries-turned-into-aggregates. "Top usage scenarios" don't always cut it.