-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Numerical sorting #226
Numerical sorting #226
Conversation
/cc @wachterjohannes |
1544ded
to
941b684
Compare
@@ -837,70 +845,85 @@ private function syncReferences() | |||
} | |||
} | |||
|
|||
public static function xmlToProps($xml, ValueConverter $valueConverter, $filter = null) | |||
public static function xmlToProps($xmlData, ValueConverter $valueConverter, $filter = null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We split the properties into 3 separate DOM documents, for LONG, DECIMAL and STRING
wow, pretty involved. i wonder if we should not use http://www.postgresql.org/docs/9.3/static/datatype-json.html or something similar, if we have to go away from simply serializing to xml anyways. the json field should be efficient for search - and it might better allow for mixed data (unless i did not grasp the full issue). |
@dbu would storing in JSON hold any advantages here? (from what I can gather it might), but I don't think JSON column types are supported in most versions of MySQL. |
hm, indeed mysql might be a problem here. and sqlite, and old postgres versions. just wondering if there is something simpler than xml if all we store is just a "hashmap" with a known value format. but indeed, xml works and anything else opens a new can of worms. |
The other option would be to have a separate table for the properties, which is something similar to what EZ publish does I think. But then thats basically a different transport. |
and we end up with EAV with its performance problems. |
Maybe it could be an option if we adopt a more modular architecture in Jackalope "2.0". |
I am generally open to this approach. Performance is important and also the behavior of Jackrabbit in this case. |
Updated. Query tests are failing locally because of query parsing issues.. which I don't think are related. Next I will run this through @lsmith77 s benchmarking script and see what happens. |
@@ -207,6 +207,10 @@ public function __construct(FactoryInterface $factory, Connection $conn) | |||
private function registerSqliteFunctions(PDOConnection $sqliteConnection) | |||
{ | |||
$sqliteConnection->sqliteCreateFunction('EXTRACTVALUE', function ($string, $expression) { | |||
if (null === $string) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
numerical_prop
can be nullable.
Have updated and added some performance stats. Basically it is expensive enough to be a problem at the moment. Although, the MySQL perf. penalties That said -- the penalty is always going to be significant. Shall I make this an option? |
yeah .. I think it will need to be an option, ideally changeable at runtime. |
if (!empty($xmlData['long_props'])) { | ||
$xmlFields[] = $xmlData['long_props']; | ||
} | ||
if (!empty($xmlData['decimal_props'])) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we do not actually need separate columns here.. we can just have a numberical_props
column cast to decimal regardless.
@lsmith77 at one level we need to know at code-time because we need to persistently populate the number column, or I guess we could always populate that column. A runtime option could be used to toggle if we select from / order by it. We could also always store all the value in |
will we only populate those properties when the values are actually numeric? but yeah I think its ok to always populate them. |
@@ -0,0 +1,32 @@ | |||
SELECT \* FROM [nt:unstructured]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is the purpose of committing this file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
everything in this folder is an accidental commit.
restarted the build. but the errors are only about query parsing tests. @dantleech can you squash the commits? i would say this is ready to merge now unless you know of something we missed. |
$propsData = array('dom' => $dom); | ||
if ($row['numerical_props']) { | ||
$numericalDom = new \DOMDocument('1.0', 'UTF-8'); | ||
$numericalDom->loadXML($row['props']); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks wrong.
433adb9
to
a378a50
Compare
ok.. tests are fine locally after rebasing and I fixed an issue and added a test when copying nodes. Lets see what happens with travis. |
@@ -1055,7 +1120,6 @@ public function getNode($path) | |||
$query = ' | |||
SELECT * FROM phpcr_nodes | |||
WHERE path = :path | |||
AND workspace_name = :workspace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doh. wtf.
27988c9
to
f8862a5
Compare
ok! The tests are fine now -- the failing postgres test corresponds to the existing failing test in master. |
@@ -0,0 +1,32 @@ | |||
SELECT \* FROM [nt:unstructured]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
benchmark.back - did you accidentally commit this?
apart from the benchmark.back folder, this looks good to me. @lsmith77 can you also do a final review? |
f8862a5
to
acd30df
Compare
@@ -48,7 +48,7 @@ public function testDefaultQuery() | |||
$this->nodeTypeManager->expects($this->once())->method('getSubtypes')->will($this->returnValue( array() )); | |||
|
|||
$query = $this->factory->createQuery($this->factory->selector('nt:unstructured', 'nt:unstructured'), null, array(), array()); | |||
list($selectors, $selectorAliases, $sql) = $this->walker->walkQOMQuery($query); | |||
list($telectors, $selectorAliases, $sql) = $this->walker->walkQOMQuery($query); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tlectors??
- New column "numerical_props" which is populated by numerical properies and which is used exlusively for ordering.
acd30df
to
38ca930
Compare
Removed the accidentally comitted benchmark files. |
wondering if we could make the |
I think that it makes sense that But we could do that in another PR I think. |
Created #237 |
the travis fail is only the postgres problem. +1 to merge from me. (and maybe we should skip the failing test when the db is postgres and the env travis, if we can't find the problem, to have a reliable build) |
This PR adds an extra column
numerical_props
which is populated withLONG
,DECIMAL
andFLOAT
values (in an XML doc).When sorting the query will ORDER first by casting the value of the property in the
numberical_props
column and then by the standardprops
column.Benchmarking
Master:
This PR: