| Summary: | VFS IOService sorts the version records by commit date instead of naturally as they happened | ||
|---|---|---|---|
| Product: | [Retired] JBoss BRMS Platform 6 | Reporter: | Petr Široký <psiroky> |
| Component: | Business Central | Assignee: | Alexandre Porcelli <porcelli> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Lukáš Petrovický <lpetrovi> |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.0.0 | CC: | lpetrovi, pzapataf, rrajasek |
| Target Milestone: | ER6 | ||
| Target Release: | 6.0.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-08-06 20:15:43 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
Not sure this actually has to do with the migration tool but with the VFS service itself. Please, verify and if that might involve a platform wide impact, consult with Uberfire engineers before changing Pedro, yes, you are right, it is not specific to jcr2vfs migration tool I just stumbled on it when testing the tool. That's the reason I originally assigned this BZ to Alexandre. We had a little chat about that and he asked me to create one. I reassign it to Porcelli then, since it involves UF / VFS changes. Feel free to reassign if we can help with that, but this might have a platform impact it's best assessed by him. Issue fixed on UberFire master and product branches: https://github.com/droolsjbpm/uberfire/commit/09afc07dc https://github.com/droolsjbpm/uberfire/commit/5d8d2c884 VERIFIED. |
Description of problem: I hit the following issue when testing the jcr2vfs migration tool. Versions records (e.g. commits in case of git) are sorted by the commit date instead of how they actually happened (the order in which they were committed). See the example. Following is returned by 'git log' (the number in parentheses is just for reference, not part of the actual output): (1) commit 558c4b05ed4f6ab241e2c8bab17fb0940dd0871a Author: Petr Siroky <psiroky> Date: Thu Aug 15 10:08:45 2013 +0200 Underage.rdrl - salience updated to 11 (2) commit 1b9e2799199bf032815f18f169f1264b68d3f657 Author: mic <null> Date: Wed Oct 1 04:54:34 2008 +0200 (3) commit 23f53aaf7ef00df10119f20f18fbe77eecfe752d Author: Petr Siroky <psiroky> Date: Fri Jul 26 17:59:37 2013 +0200 Following is the code used to get version records using VFS API: VersionAttributeView<Path> versionAttributeView = ioService.getFileAttributeView(path, VersionAttributeView.class); VersionHistory history = versionAttributeView.readAttributes().history(); return history.records(); However this code returns the records in order: 2, 3, 1 - sorting them by date. It should instead return them in order 1, 2, 3 (or maybe 3, 2, 1 - not sure if its better to return latest as first or oldest as first) Version-Release number of selected component (if applicable): Uberfire in 6.0.0-ER5 (and most probably also in 0.3.0-SNAPSHOT and 0.4.0-SNAPSHOT) Additional info: This should not be an issue when the repository is accessed only through UI (kie-wb) as it commits the changes in correct order. However if we allow also remote access this could bring some issues when displaying the asset history. Also this pops up when using the jcr2vfs migration tool as it uses the dates from past to align the history with the JCR repo.