|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [OSSTEST PATCH 00/13] Speed up and restore host history
On 11/11/2019 12:00, Ian Jackson wrote:
> Sander Eikelenboom writes ("Re: [Xen-devel] [OSSTEST PATCH 00/13] Speed up
> and restore host history"):
>> Not mend to bike shed, so just for consideration:
>
> Suggestions are very welcome. Be careful, I'm still looking for a
> co-maintainer :-).
/me is ducking under the table ;)
Seems to be quite a lot of intracate Perl, I never was a prince of Perl
and that hasn't got any better by not using it actively the past years.
>> - Have you considered (inline) css for the background colouring, or does
>> it have to be html only ?
>
> There is no particular reason why it shouldn't be CSS. Is there a
> reason why doing it in html causes problems for you ?
Not really, but especially applying style to alternating rows is now
quite simple with pseudo classes:
tr:nth-child(even){
background-color: grey;
}
tr:nth-child(even){
background-color: white;
}
You could stuff this in a <head><style> ... </style></head>,
so you don't have to repeat this every row for the common case.
For any special cases you could overrule based on class.
I happen to find it one of the most useful CSS features.
https://www.w3.org/wiki/CSS/Selectors/pseudo-classes/:nth-child
> The background colours for the cells are made with
> report_altcolour
> report_altchangecolour
> in Osstest/Executive.pm.
>
> report_altcolour returns something that can be put into an element
> open tag, given a definite indication of whether the colour should be
> paler or darker.
>
> report_altchangecolour is used to produce background colours which
> change when the value in the cell changes.
>
> I think it would be easy to replace bgcolour= with some appropriate
> style= and some CSS. Patches - even very rough ones - welcome.
>
>> - And for caching perhaps a materialized view with aggregated data only
>> refreshed at a more convient time could perhaps help at the database
>> level ?
>
> Maybe, but currently the archaeology algorithm is not expressed
> entirely in SQL so it couldn't be a materialised view. And converting
> it to SQL would be annoying because SQL is a rather poor programming
> language.
It is a poor programming language, but it is very good at retrieving and
modifying data. Sometimes it takes some effort to wrap your head around
the way you have to specify what data you want and in what for, without
being to explicit in how it is supposed to be retrieved.
> It might be possible to, instead, have table(s) containing archaeology
> results. I hadn't really properly considered that possibility. That
> might well have been a better approach. So thank you for your helpful
> prompt. I will definitely bear this in mind for the future.
If I remember correctly Postgres is being used, perhaps there is stull
some relatively low hanging fruit when analyzing the performance of the
queries you run at the actual data.
> I'm not sure I feel like reengineering this particular series at this
> time, though. One reason (apart from that I've done it like this now)
> is that the current approach has the advantage that it doesn't need a
> DB schema change. I have a system for doing schema changes but they
> add risk and I don't want to do that in the Xen release freeze.
I understand, and I concur that that is probably the best at the moment.
I will take a look at the code somewhere this or next week and see if I
can get any familiarity with it and perhaps end up with some contributions.
--
Sander
> Regards,
> Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |