Remove timestamp in favor of the date/time selector implemented in 2023

[charlesbaer]

No description provided.

[rarsan]

Thx for this PR @charlesbaer. What is driving this change? Just to understand more as we would need to apply this consistently. Almost all queries have a codified timestamp filter in order to:

• codify and version-control a default lookback window depending on the CSA use case
• avoid inadvertently running a query across entire log bucket (or bigquery view)

The query works correctly in Log Analytics query editor, but I understand the time-range selector is basically disabled with some explanation in the UI: To use the time-range selector, remove timestamp expressions from the WHERE clause...

Would it be OK to add that as a comment next to the timestamp condition in all the SQLs for those who prefer to use time-range selector in the UI?

[charlesbaer]

Including the timestamp for basic operations actually produces a significantly degraded experience which is why I propose to remove them from all places where the date/time selector can change the SQL line into a simple dropdown selection. We still need to keep the timestamp filters for any more complicated logic that isn't a simple date restriction and that won't interact with date/time picker.

…

On Wed, Jan 24, 2024 at 12:15 PM Roy Arsan ***@***.***> wrote: Thx for this PR @charlesbaer <https://github.com/charlesbaer>. What is driving this change? Just to understand more as we would need to apply this consistently. Almost all queries have a codified timestamp filter in order to: - codify and version-control a default lookback window depending on the CSA use case - avoid inadvertently running a query across entire log bucket The query works correctly in Log Analytics query editor, but I understand the time-range selector is basically disabled with some explanation in the UI: To use the time-range selector, remove timestamp expressions from the WHERE clause... Would it be OK to add that as a comment next to the timestamp condition in all the SQLs for those who prefer to use time-range selector in the UI? — Reply to this email directly, view it on GitHub <#48 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHHRAK6BI36XF66JHIFIVKTYQE6SVAVCNFSM6AAAAABCI4STMGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBYGU3TQOBUHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[rarsan]

Understood. Thx for clarifying. How about we comment out all these timestamp filters from the SQL? Lemme know and I can help with this wholesale change in this PR. In the comment we could clarify it's in order to fall back on the preferred UI date/time selector. This way 1) the default would be the date/time selector, 2) while also leaving the end-user with the commented boilerplate code which might be needed e.g. if the SQL (and timestamp filter) is version-controlled or executed as part of an ETL pipeline... On Wed, Jan 24, 2024 at 8:28 PM charlesbaer ***@***.***> wrote:

…

Including the timestamp for basic operations actually produces a significantly degraded experience which is why I propose to remove them from all places where the date/time selector can change the SQL line into a simple dropdown selection. We still need to keep the timestamp filters for any more complicated logic that isn't a simple date restriction and that won't interact with date/time picker. On Wed, Jan 24, 2024 at 12:15 PM Roy Arsan ***@***.***> wrote: > Thx for this PR @charlesbaer <https://github.com/charlesbaer>. What is > driving this change? Just to understand more as we would need to apply this > consistently. Almost all queries have a codified timestamp filter in order > to: > > - codify and version-control a default lookback window depending on > the CSA use case > - avoid inadvertently running a query across entire log bucket > > The query works correctly in Log Analytics query editor, but I understand > the time-range selector is basically disabled with some explanation in the > UI: To use the time-range selector, remove timestamp expressions from the > WHERE clause... > > Would it be OK to add that as a comment next to the timestamp condition in > all the SQLs for those who prefer to use time-range selector in the UI? > > — > Reply to this email directly, view it on GitHub > < #48 (comment)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AHHRAK6BI36XF66JHIFIVKTYQE6SVAVCNFSM6AAAAABCI4STMGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBYGU3TQOBUHA> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#48 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHCFNXBTNWER5NRCS2OR23YQG7MLAVCNFSM6AAAAABCI4STMGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBZGI2DCNZQGU> . You are receiving this because you commented.Message ID: ***@***.***>