problem with file schemas during export from 5.4.2 to 5.7
Hi still in the process of migrating from 5.4.2 to 5.7, i have a problem with documents exported : the file schema has changed : the file:content filename was used to name the content of a file now it seems that the file:filename value is used
Before that value was empty, so that imported documents have a nameless doc.
How can I export / import filenames correctly ?
<schema xmlns:file="http://www.nuxeo.org/ecm/schemas/file/" name="file">
<file:content>
<encoding></encoding>
<mime-type>image/png</mime-type>
<filename>posix.png</filename>
<data>437cbfc3.blob</data>
<digest>9bb7d0695aada86cd4791077a04f4333</digest>
</file:content>
<file:filename><![CDATA[posix.png]]></file:filename>
</schema>
<schema xmlns="http://www.nuxeo.org/ecm/schemas/file/" name="file">
<content>
<encoding></encoding>
<mime-type>application/pdf</mime-type>
<filename>circulaire_jour_de_carence_20120224.pdf</filename>
<data>ea1e9a28.blob</data>
</content>
<filename/>
</schema>
 |
pibou Bouvret
Member (8.9K) 4 7 10 |
10/10/2013 ( History) |
The file table had indeed an empty filename field.
I updated that field using the name field of the related entry in the content table
|
pibou Bouvret
Member (8.9K) 4 7 10 |
10/14/2013 ( History) |
Can you please tell what issue (visible in the interface or not) this change fixed? I checked and the "lazy upgrade" code i was mentioning is run with MimetypeIconUpdater, on creation and modification of the document. It should not be mandatory for features to keep on working as expected, so there might be a bug somewhere if it's needed.
Also if you still have the SQL statement somewhere, i'd be happy to add it to upgrade notes.
update file f set filename =
(
SELECT c.name from hierarchy h1 ,hierarchy h2 ,content c
where f.filename is null and c.name is not null
and f.id = h1.id
and (h2.parentid = h1.id and h2.primarytype='content')
and c.id=h2.id
)
where f.filename is null ;
so that the binaries (file schema) of imported documents now have a filename.
The "files" schema might need the same kind of fix
Originally the blob did not hold a filename, hence a specific field was used to hold it. Although it's supposed to have been kept compatible (with a listener filling the other value for lazy upgrade, if i'm not mistaken), can you tell where you're seeing this issue, in case it's a break in the compatibility that can be avoided?
If you're just importing/exporting documents once, i guess the more efficient would be to identify the values to copy in the database tables and to use some kind of SQL command.
This would be interesting to add to upgrade notes anyway.
BTW, i edited the second sample : filename is empty !