no className is passed and the invocant's class is Asset. This is
due to the root. In the db, the root Asset has the className WebGUI::Asset,
and the getRoot method matches this.
Changed the failing test in Asset.t to look for a WebGUI::Asset to be returned.
Added two tests to Asset.t to validate the object returned by Asset->getRoot method.
Reverted previous work and updated the POD for Asset->new.
- fix: Search results not showing synopses
- fix: Redirects get displayed inside page layouts as '0'
- fix: Mysterious "0" Appearing When Admin Is Off
- fix: Deletion of Products
the lastUpdated method on a user, for example. I've made two changes
to try and fix these:
1) Changed the tests to use cmp_ok instead of ok, so that future failures
will print the measured times as a debug, like is and isn't do.
2) Reversed the order of the method and time measurement. This might help
the difference stay smaller since the two statements are closer.
instead of the macro processor, all tests which default behavior (no parameters)
were broken.
The next series of test commits will remedy this on all tests. Also during
this time, each test will be augmented to abort the test if the Macro
cannot be loaded.
The check for rolling back the pbversion0000000000001 tag wouldn't log any
errors because it was after the return 0 statement.
If a set of assets that were programmatically generated were rolled
back, and the assets had a parent child relationship then there's
a race condition that could cause the parent to be purged before
child. Since purging the parent _also_ purges the child, the system
would try to purge the child twice and this causes a fatal error.
Programmatically generating the assets causes their revisionDates
to be the same, and that causes the return order of the assets to
be uncertain.
The solution is to generate the list of assets to be rolled back
by revisionDate _AND_ lineage. This guarantees that children are
purged first.
This bug was exposed in t/Macro/RootTitle.t However, the bug
seems to be system dependent since the revisionDate depends on how
fast the system can create assets.