https://bugzilla.wikimedia.org/show_bug.cgi?id=32165
--- Comment #5 from Markus Krötzsch <mar...@semantic-mediawiki.org> 2011-11-03
09:33:20 UTC ---
In general, having more special properties does not really hurt us. However,
getting the values for such meta-properties can hurt for two reasons:
(1) More code is needed in some cases to get at the right values. This might
even require new hooks.
(2) Setting the values can take time since you get additional database lookups
on all edits, refreshs and maybe even previews.
Concern (1) does not seem to be an issue here since "creation date" can be set
in the same places as "modification date". To tackle (2), it would be good to
make it configurable which additional meta-properties should be stored by SMW.
This could be combined with some better general architecture for adding such
properties.
But "modification date" is probably not a good role model for new properties of
this kind. Many properties could even be determined during parsing when all
other property values are set (e.g., size, creation date, metadata about
files). "Modification date" is special because during parsing you do not know
if the date should be the current time (happens if a user just edited) or the
time from the MediaWiki database (happens when the page data is refreshed by a
job). This is why the code for _MDAT is more complicated and found in two
places (one that sets the date when saving an edit, and a second one that
retrieves the date from the database if it was not set already). For most such
properties, it should be possible to get the right information in the second
place (just before saving the data). The only exception are properties that
change on edits but not on refreshs ("last editor" is such an example).
Overall, there are three places to set such property data:
(a) Right after parsing (happens on every preview)
(b) Right before saving an article change (happens only when pressing "save")
(c) Right before saving SMW data (happens on all changes and updates)
No property can rely on (b) only since this step is skipped when updating page
data in a job. Relying on (a) would be good for properties that can easily be
obtained from the page without extra database lookups (page size, maybe file
properties, ...). Moreover, (a) is necessary if the property value should show
up in the Factbox (data that is added in (c) will be too late for the Factbox
in some cases). Finally, (c) is good for setting properties that are harder to
obtain (DB lookup).
Modification date uses (b) and (c); I assume your code does the same. But
"creation date" would only need (c) to work. Overall, we should probably have
hooks in each of the places to separate such code for easier maintenance. Then
one could have a separate file with simple hook implementations for a/b/c as
needed for various special properties, and one could have a configuration to
state which of them should be used.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
