CMX crash and realtime retain failure

[mcrossley]

Well, that's not right at all!

Something has obviously gone wrong at some point. I'm reworking the MySQL stuff at the moment, so I'll take a look at getting it fixed tomorrow...

[mcrossley]

Hang on, the problem is purely in the help text. You should just try entering the text as "value unit". So for example "10 DAY"

See: https://dev.mysql.com/doc/refman/8.0/en ... -intervals

[HansR]

Indeed. Fooled by the help text. Room for improvement here.
Thanks!

I suggest to give just the number (of days) and have days implicit. Nobody is going to retain more than a month of realtime unless you would want stress the limits of your database. And even then, you could give a 1000 days, 10.000 or whatever (would that be possible?). No formatting of (partial) SQL statements must be left to the user. Users are not programmers, they are users. CMX is being/becoming too much a programmers program iso of a meteo program.

[mcrossley]

The problem is migration. People will already have configured that setting previously and may have 2 WEEK or 1 MONTH set for instance

I think you may be surprised how much real time data some people are retaining!

Users are not programmers, they are users. CMX is being/becoming too much a programmers program iso of a meteo program.

Yes, with hindsight it may have been better to to have a number of days field, but that isn't what was set up originally by Steve years ago.

I'm not sure I agree with that statement. I have been trying to simplify the settings screens by removing irrelevant settings, and removing the need for users to edit Cumulus.ini to alter settings, so I would argue the opposite case.

[freddie]

The problem is migration. People will already have configured that setting previously and may have 2 WEEK or 1 MONTH set for instance

I think you may be surprised how much real time data some people are retaining!

Users are not programmers, they are users. CMX is being/becoming too much a programmers program iso of a meteo program.

Yes, with hindsight it may have been better to to have a number of days field, but that isn't what was set up originally by Steve years ago.

I'm not sure I agree with that statement. I have been trying to simplify the settings screens by removing irrelevant settings, and removing the need for users to edit Cumulus.ini to alter settings, so I would argue the opposite case.

I would argue the opposite case too - you have done a lot of work to make settings user-oriented.

Regarding the setting in question - how about a drop-down menu with some choices, with the translation to the SQL equivalent as the submitted values?

[mcrossley]

Regarding the setting in question - how about a drop-down menu with some choices, with the translation to the SQL equivalent as the submitted values?

How about...

realtime.jpg

[HansR]

@mcrossley, @freddie:

The problem is migration. People will already have configured that setting previously and may have 2 WEEK or 1 MONTH set for instance

I think you may be surprised how much real time data some people are retaining!

Any numbers and a reason why?

Users are not programmers, they are users. CMX is being/becoming too much a programmers program iso of a meteo program.

Yes, with hindsight it may have been better to to have a number of days field, but that isn't what was set up originally by Steve years ago.

OK. Maybe freddie's suggestion may help here. I could live with that.

I'm not sure I agree with that statement. I have been trying to simplify the settings screens by removing irrelevant settings, and removing the need for users to edit Cumulus.ini to alter settings, so I would argue the opposite case.

I see what you have done with the settings and I think that is a great action (like so many other actions). My remark comes not so much from this specific setting as well as from the fact that all other SQL is actually left to the user. The user is invited (at least not discouraged) to modify all kinds of code around - and within - CMX creating issues of its own (is there a repository of SQL queries in use?).

Anyway, further irrelevant probably, so just take it as a loose remark

EDIT: Trying to post this reply I saw your solution. Seems great to me.
Btw: those fields are always below each other, is it possible to have them beside each other?

[freddie]

Regarding the setting in question - how about a drop-down menu with some choices, with the translation to the SQL equivalent as the submitted values?

How about...
realtime.jpg

Perfect

[mcrossley]

Btw: those fields are always below each other, is it possible to have them beside each other?

Sadly no, there is a layout option for side-by-side, but it is an all or nothing option, it has to apply to the whole page. I have made a request that it be supported on a sub section basis, as have other people, but no response

[mcrossley]

My remark comes not so much from this specific setting as well as from the fact that all other SQL is actually left to the user. The user is invited (at least not discouraged) to modify all kinds of code around - and within - CMX creating issues of its own (is there a repository of SQL queries in use?).

Originally because the MySQL is not something Cumulus MX is "interested" in, like MQTT etc is is something that it can provide data for, but has no interest in reading back. If MX used it as a storage resource then yes it should a fixed schema to ensure compatibility.

MX provides a suggested schema, which probably the vast majority of SQL users will use and that is fine.

But if people want to freewheel they can - I do, I store additional data that is of interest and useful to me. I have also added triggers, stored procedures and additional tables to drive my web site. I guess my view is if you are competent enough to stray away from the default you are knowledgeable enough to sort out any consequences, or live with them

For me its a balance, you are proscriptive with settings and reduce flexibility, or allow have defaults but allow customisation and increase flexibility.

[HansR]

But if people want to freewheel they can -

Yes. And that is great and good. My own coding started out there as well. No problem.

But let's be honest: there is e.g. a lot of code which apparently is based on SQL (PHP procedures with implicit SQL) and there is a lot of variability in there. I think those queries and that structure could/should become part of Core-CMX. The procedures around it as well. If it were only those things were assembled in some repository (or is it already? I could have missed it) where at least the basis is maintained / stabilised. The same holds for javascript.

It's the divergence which disturbs me.

For me its a balance, you are proscriptive with settings and reduce flexibility, or allow have defaults but allow customisation and increase flexibility.

CMX is at the basis and has by definition a lot of divergence because of what you want to serve.
CUtils for a data presentation needs convergence. That is a big difference.

I don't think we differ very much though you bend more to one side I more to the other.
The difference looks big, but the feet are close.

If CMX had not been so limitless (which it isn't), CUtils had not become so limiting (which btw it isn't either).

But anyway, you never know, maybe sometime a nice discussion over a pint or two on applications, how to setup things, users and developers