Closed dbu closed 11 years ago
also related, why do we duplicate contentType in the file and with the mimeType of the jcr:resource? i would love to not map contentType on the file in phpcr and always forward to the jcr:resource, why would we not want to do that?
and more in the same direction, the size property should not be mapped but calculated as $this->node->getNode('jcr:content')->getProperty('jcr:data')->getLength()
. i will do a PR on phpcr-odm to expose getSize() on the Resource document to make this easier.
That makes sense. In general (size, contentType, modified), there is no performance issue for batch queries? Fe. getting the latest modified large files from many files (+10000). And are joins supporting this for jackrabbit and dbal?
Regarding contentType. For elFinder I think it went wrong for uploading files, by default it got "application/stream", but that could have been caused by a wrong order in handling and determining the mime type. While changing we should check this (and probably add a test for it).
regarding the size, i just created https://github.com/doctrine/phpcr-odm/pull/330
there is a length construct in the query language http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/query/qom/QueryObjectModelFactory.html#length%28javax.jcr.query.qom.PropertyValue%29
the unfortunate thing is that for those informations, you would indeed need to join the file nodes with their jcr:ontent nodes, but if that was good enough for the people designing jcr i think it should be good enough for us. i would prefer that over duplication of such data (they can go out of sync which could be quite annoying).
Ok. Just thought about the File documents metadata. If we change something different then the content shouldn't we also trigger the modified? Fe. Changing the file name via elFinder.
probably a question of definition what modified means. not an easy question, either. i would opt for saying only actual file changes would change the modified, and if somebody needs more, he can extend the classes and add that. its easier that way than removing some setters changing things. wdyt?
True, I think it is ok and it would be great if we could follow the same workflow a user would have with a "real" file on a computer. Just checked (on mac) and I see that changing the filename does not change the modified date there :-)
this and #10 involve some BC breaks needing data migrations. @rmsint do you have time to work on this in the next days?
@dbu, I will give it a try (I have untill thursday before begin offline again for some days.)
Regarding modified and the doctrine mapping: Doctrine\Phpcr\File
extends Doctrine\Phpcr\Media
. For the Doctrine\Phpcr\File
we do not want to map the "modified" information?
For a Doctrine\Phpcr\Media
we do want to have this information, it can be fe. a video url. The Doctrine\Phpcr\File
doctrine configuration automatically inherits the "modified" mapping from Doctrine\Phpcr\Media
. If we do not want the "modified" information for a Doctrine\Phpcr\File
it means that it cannot extend Doctrine\Phpcr\Media
, and we start to duplicate code and doctrine mapping configuration? Or is it possible to remove a field mapping in the doctrine mapping configuration?
maybe we should drop modified from media and make media an abstract class? i have the impression it can not do anything on its own? and then have LinkedMedia extends AbstractMedia with a mapped modified date, or something like that?
see #63
while migrating an older cmf website, i realized that we have a bit of a stupid situation. currently, we define both mix:created and mix:modified on the
File
. but nt:file only would have mix:created, while the mix:modified is part of the jcr:resource child.don't ask me why its like this, but it is. the problem with the current thing we have is that we duplicate the "modified" information both in the file (which is nt:unstructured until we do #10) and the content which is jcr:resource i think from our interfaces point of view, it totally makes sense that all of this is on the file itself. i suggest to remove the mixin and mapping, and overwrite the BaseMedia getter and setters for "modified" information in the phpcr file class to forward to the resource.
http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/nodetype/package-summary.html#mix:created