Enhancement of SQL output

[dynasource]

this deserves attention regarding readability. Having 1 line of SQL is not really practical.

[samdark]

Yes. Automatic formatting could be useful.

[dynasource]

a similar usecase can be found for the display of database exceptions pages. Where do we want to put the formatting logic?

• in the core?
• inside a helper?
• inside Command?
• somewhere else?

[dynasource]

perhabs formatting by JS with an Asset

[cebe]

I'd prefer to not introduce too much javascript which could interferre with the loaded page so a PHP solution like it is used in apidoc extension can be used: https://github.com/yiisoft/yii2-apidoc/commit/1b5813c4960d9a0a9d9f0d29912c5d578b2da9de

[dynasource]

on the contrary, we will have more places in which SQL formatting could be appropiate. This will pollute the core while JS could be unobtrusive.

What about adding class="mysql" to those containers. Then the code would not have to interfere?

[samdark]

How JS could be unobtrusive? It pullutes dependencies and we have a plan to move all JS dependencies out of the core...

[dynasource]

• when you attach the JS to a mysql class like class="mysql"
• this Asset won't have to be in the core and can be supplied as a seperate extension, otherwise we have to integrate it inside the PHP code somewhere

[samdark]

If it's supplied by debug then it should be fine.

[dynasource]

how should we integrate it with \yii\db\Exception?https://github.com/yiisoft/yii2/blob/master/framework/db/Schema.php#L635

isnt this a clear case to introduce an Event to the Exception architecture?

Then we can handle all inside the debug extension.

[samdark]

isnt this a clear case to introduce an Event to the Exception architecture?

Isn't it too late to process events when there's an uncaught exception?

[samdark]

I'd introduce $sql property in DB Exception class so it could be obtained.

[dynasource]

just by including googles prettifier and some PHP regex

<script src="https://cdn.rawgit.com/google/code-prettify/master/loader/run_prettify.js"></script>

we can get this:

Do we like this?

[alexraputa]

👎 It might look better.

[samdark]

@alexraputa any proposals?

[rob006]

Just compare this to real formatters: http://www.dpriver.com/products/sqlpp/sqlexamples2.php

[alexraputa]

@rob006, 👍 it looks much better.

[dynasource]

Just compare this to real formatters: http://www.dpriver.com/products/sqlpp/sqlexamples2.php

this is a paid one? http://www.dpriver.com/buynow.php

It would be nice to have use an open source library for this. This can be time consuming to create yourself.

[rob006]

First result from google: https://github.com/jdorn/sql-formatter

[dynasource]

jdorn looks nice indeed. A nice example at http://jdorn.github.io/sql-formatter/

Unless people have better proposals, I'll integrate that one.

[dynasource]

I've looked into the Sql formatters. It seems that 'jdorn/sql-formatter' has the most stars on github and from what I have seen, also the most readable output.

It has one disadvantage though. Readability goes at cost of the length of the page. Should I integrate a 'onclick' prettify toggle?

[samdark]

Length doesn't matter in debug mode.

[dynasource]

well, having many of these page filling queries is quite obtrusive. People have to expect another userexperience on the DB debug panel

[samdark]

Won't matter much.

[dynasource]

it matters on a 30 inch ;)

[cebe]

It has one disadvantage though. Readability goes at cost of the length of the page. Should I integrate a 'onclick' prettify toggle?

That would be good to have otherwise scrolling through a lot of querys is tedious when they are complex.

[samdark]

The toggle should be sticky then. Its state should survive page reloads.

[dynasource]

status update: jdorn/sql-formatter does not to seem to be stable and gives errors with certain SQL's. This is not desired behavior for inclusion.

[samdark]

@dynasource worth reporting to jdorn/sql-formatter issues...

[dynasource]

I'm questioning to keep it simple instead of having a library to fix it. On the other hand, perhabs we should adopt flexibility and make the developer to decide which sql formatter he should use

[samdark]

Well, reporting it is a good idea anyways.

[samdark]

Some degree of flexibility is good.