Datetime values not rendering in results table

Hi there – We’re seeing an issue where Metabase (0.32.5), looking at a MySQL 5.7 instance, isn’t properly returning datetime values; instead displaying null. Any function that manipulates the datetime value causes the value to render properly, (e.g., SELECT CONCAT(datetime) yields a value in the table, but simple SELECT datetime yields null).

Has anyone else encountered this issue?

Hi @dodongo
Do you see the same behavior in the latest release 0.32.9?
What is the exact MySQL version?
Do you see any errors in the Metabase log or browser console, when it’s empty?
Can you check the returned result to see if it this is a backend or frontend issue? Open browser console Network-tab and check Response data of the request.

EDIT: It might be similar to this issue, but there’s very limited details and no way to reproduce:
https://github.com/metabase/metabase/issues/10285

Do you see the same behavior in the latest release 0.32.9?

Actually, I happen to be cookin’ with the latest 0.33rc2 on my laptop, and it does not appear to exhibit this behavior. Maybe this accidentally got addressed :slight_smile:

What is the exact MySQL version?

Unsure of sub-releases, but whatever is the current 5.7.x release is almost surely what we’re running.

Do you see any errors in the Metabase log or browser console, when it’s empty?

Nope, nothing that seems indicative of an error.

Can you check the returned result to see if it this is a backend or frontend issue? Open browser console Network-tab and check Response data of the request.

Is this maybe what you’re after?

  1. rows: [[1, null], [2, null], [3, null], [4, null], [5, null], [6, null], [7, null], [8, null], [9, null],…]

  2. 0: [1, null]

  3. 0: 1

  4. 1: null

  5. 1: [2, null]

  6. 0: 2

  7. 1: null

  8. 2: [3, null]

  9. 0: 3

  10. 1: null

  11. 3: [4, null]

  12. 0: 4

  13. 1: null

  14. 4: [5, null]

  15. 0: 5

  16. 1: null

  17. 5: [6, null]

  18. 0: 6

  19. 1: null

  20. 6: [7, null]

  21. 7: [8, null]

  22. 0: 8

  23. 1: null

Not sure what to extrapolate here; the query evaluates properly in MySQL Workbench.

@dodongo
Interesting. So all the null returns should be a datetime column value? And when you CONCAT(column), then you see the value in the response data?
Well, if it is fixed in 0.33.0-preview2, then it might have been an issue in the earlier 0.32.9, which has been fixed on master/notebook-mode and will end up in 0.33.0

Yeah, that’s exactly what I’m seeing. I don’t even have a good guess as to what might be at issue, but I’m encouraged seeing what sure looks like an improvement in the new version. Was already planning to move on the 0.33 release once it’s finalized; this just reaffirms that decision!

Just for the sake of closing the loop, and because this is a fun, obscure, what-the?? issue, I’ve been talking this morning with another engineer, and we’re now pretty sure that the column doesn’t render properly when datetime(6) entries with a non-zero decimal value are being chucked along. I completely understand if this will remain unaddressed in the 0.32.x cycle. Well worth it to see 0.33 ready to go! :slight_smile:

@dodongo
Wait, so you’re using DATETIME(6) for the problematic column? Wouldn’t that only contain year-month? I’m not sure if Metabase can handle that. You might want to create a view for that table and just return a simple DATE column (year-month-01)

In MySQL (>= 5.6.4), datetime(6) is 6-decimal (microsecond) precision; it includes year / month / day values as well. It seems that having a nonzero value after the decimal is what’s causing the omission behavior.

@dodongo
Ahhh, I thought it behaved like CHAR(6).
I think it might be because microseconds are not supported in Metabase:
https://github.com/metabase/metabase/issues/1889

Well, the good news is that it does seem to work in 0.33 on my local machine, so looks like just a matter of deciding when to take the plunge!

1 Like