Defining volume_priority expliclty in storage_configuration

[den-crane]

Now a volume_priority is defined by an order in XML.
This is unorthodox way because an order in XML should not have sense.

So please implement volume_priority

<storage_configuration>
    ...
    <policies>
        <moving_from_ssd_to_hdd>
            <volumes>
                <hot>

                    <volume_priority>1</volume_priority>

                    <disk>fast_ssd1</disk>
                    <disk>fast_ssd2</disk>
                    <max_data_part_size_bytes>1073741824</max_data_part_size_bytes>
                </hot>
                <cold>

                    <volume_priority>2</volume_priority>

                    <disk>disk1</disk>
                </cold>
            </volumes>
            <move_factor>0.2</move_factor>
        </moving_from_ssd_to_hdd>
...
</storage_configuration>

[gerowam]

This bit me pretty hard recently -- would be great to get this fixed.

[alexey-milovidov]

because an order in XML should not have sense

The order in XML makes sense.
For example, when you have XHTML, and you write <p>Hello</p><p>World</p> they are guaranteed to appear in order.

[ilejn]

The order in XML does not make sense until it is specified in XSD. I believe that in XHTML spec there is xs:sequence somewhere.

Realistic scenarios that lead to serious issues can be mitigated by #58533 are about generating CH config files via XSLT/Python/whatever.

[DougTidwell]

XML, like SGML before it, is great at modeling two things: Sequence and Containment. So if you want to say an element contains an A, a B, and a C in that order, you use something like this:

<clickhouse>
<a/>
<b/>
<c/>
</clickhouse>

The order of elements is always preserved by the XML parser, and it's represented in the DOM.

XML gets clumsy when you try to represent more complicated data like triples (anyone using RDF?), but no matter what you do, the order of the XML source is always preserved.