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>
0 votes

1 answers

1009 views

ANSWER

Hi,

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.

10/11/2013

Hi this problem seems to occur on some documents based on a custom doctype implementing the file schema. I don't really understand when the listener you mentionned is supposed to run, but there might have been some kind of problem with it as some documents behave as expected. I will follow your advice and check which field should be updated in the database.

BTW, i edited the second sample : filename is empty !

10/12/2013



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

0 votes



Hi,

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.

10/14/2013

The SQL used to update the field is :

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=&apos;content&apos;)
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

10/14/2013

Thanks! I'll add it soon (see https://jira.nuxeo.com/browse/NXDOC-240)
10/15/2013