The code for the sort_by parameter is in eZContentObjectTreeNode::createSortingSQLStrings (kernel/classes/ezcontentobjecttreenode.php).
Thanks for that.
Which datatype are you using? If it's not publicly available, can you post the code from the functions sortKeyType and sortKey?
Ah..
I think you caught me being stupid (and pointed me in the right direction).
The datatype in question is one I built myself (my first attempt at creating
a datatype actually) and is loosely based on the Fats Neutron verson of the country
datatype. I call it cfselection (content fed selection) and it's simply a rather vanilla
multiple selection, except that it takes its option list from the content tree. The data is
stored in a comma delimited string.
And I see that neither of the functions you've mentioned are even part of the datatype which is probably a pretty good way towards an explanation and solution.
May I assume that these functions are called from somewhere outside the datatype itself?
May I assume that these functions are called from somewhere outside the datatype itself?
Yes, they are. The result of the function sortKey is stored in the db ezcontentobject_attribute table in the field sort_key_text or sort_key_int, depending on what the sortKeyType function returns. eZContentObjectTreeNode::createSortingSQLStrings will know which field to use by calling sortKeyType.
This is sort_by 'attribute' that we're talking about, right?
Or maybe not? If these sort/key functions in the datatype are enough
to guarantee sorting, why does the documentation for sort_by attribute say that only a hand full of datatypes are supported?
Is the documentation out of date? (Please say yes)
This is sort_by 'attribute' that we're talking about, right?
Yes, we are.
If these sort/key functions in the datatype are enough
to guarantee sorting, why does the documentation for sort_by attribute say
that only a hand full of datatypes are supported?
Not every datatype in the kernel has implemented these functions.
But if I implement the functions in my datatype(s), then attribute sorting will work correctly for them as well? Is that what you're telling me Kristof?
[me]May I assume that these functions are called from somewhere outside
the datatype itself?[/me]
[Kristof]Yes, they are. The result of the function sortKey is stored in the db
ezcontentobject_attribute table in the field sort_key_text or
sort_key_int, depending on what the sortKeyType function returns.
eZContentObjectTreeNode::createSortingSQLStrings will know which field to
use by calling sortKeyType.[/Kristof]
When are these sortKeys persisted to the DB?
When sorting works correctly, I'll have several thousand records to import. Do I need
to worry about the sort_key attributes with each record, or is that handled by the core during normal object creation?
