Hello, The tree of data was effectively slightly different between JBoss and Tomcat in previous Nuxeo versions. Because we worked on making that tree follow the same layout in all distributions, there are also some differences between previous versions of Nuxeo and the current one. Anyway, nuxeoctl script should have warned you at startup: its checks functions should fail the start when encountering an old data layout.
Are you starting Nuxeo without calling nuxeoctl script from your /etc/init.d/nuxeo-dm ? Would you be able to tell us the differences you found between both versions ? Thanks, Le 03/12/10 09:49, Nicolas SARMIR a écrit : > Hi, > > Finally i solve my problem by backup the database and the binaries and > install them to a new clean server. and it > works fine without changing anything in my configuration files. > I had this issue because i was migrating from nuxeo 5.3.2 jboss zip package > to nuxeo 5.4.0 tomcat deb package. The > tree of data seems to be different and that's why i had conflict. > > Thanks for your help. Regards, Nicolas. > > On 30.11.2010 18:10, Florent Guillaume wrote: >> This is too little information to conclude anything. >> Please compare the databases before and after the shutdown. >> If you could provide a full dump of the tables "hierarchy" and >> "content", with the URL that fails, that would help. >> >> Florent >> >> On Tue, Nov 30, 2010 at 5:11 PM, Nicolas SARMIR >> <[email protected]> wrote: >>> here is the output ( i didn't restart nuxeo): >>> nuxeo=# select * from hierarchy where parentid = >>> 'b7854e48-5698-49d8-b360-8c084aca65ac'; >>> id | parentid >>> | pos | name | isproperty | primarytype | ischeckedin | baseversionid | >>> majorversion | minorversion | isversion >>> --------------------------------------+--------------------------------------+-----+---------+------------+-------------+-------------+---------------+--------------+--------------+----------- >>> >>> de708595-fcc6-4f04-b0ec-b80556dcf2f4 | >>> b7854e48-5698-49d8-b360-8c084aca65ac >>> | | content | t | content | | >>> | | | >>> 614c7a88-cac9-4d85-bba0-1d2f32b30135 | >>> b7854e48-5698-49d8-b360-8c084aca65ac >>> | 0 | files | t | file | | >>> | | | >>> (2 rows) >>> >>> As you can see the ids don't match... It is a big problem because my DM >>> became more and more corrupt each time i have to restart it. >>> >>> Thanks, Nicolas. >>> >>> On 30.11.2010 17:01, Florent Guillaume wrote: >>> >>> It's very strange and shouldn't happen. >>> >>> But you misunderstand the ids that you see. The id visible in the URL >>> is the document id. The id visible in the content table is usually the >>> id of a complex property that's a child of the document itself. >>> Please check what's in your database like this: >>> select * from hierarchy where parentid = >>> 'b7854e48-5698-49d8-b360-8c084aca65ac' >>> You should see as ids the ids present in the content table. >>> >>> Please tell us what you see there. >>> >>> Florent >>> >>> >>> On Tue, Nov 30, 2010 at 4:03 PM, Nicolas SARMIR >>> <[email protected]> wrote: >>> >>> Hi, >>> >>> I've a curious and mostly critical issue: >>> >>> I'm using Nuxeo 5.4 deb package on a debian with postgresql and Tomcat. All >>> seems work fine but when i restart the /etc/init.d/nuxeo-dm daemon, i lost >>> all my download link refer to my documents. >>> For example, i checked with a document i upload before i restart. >>> >>> After reboot i search it in the database and i have two entries: >>> >>> nuxeo=# SELECT * FROM content WHERE name='Hiver.jpg'; >>> id | >>> name | length | data >>> | encoding | digest | mime-type >>> ----------------------------------------------------------+-----------+--------+--------------------------------------------------------+------+------+------------ >>> >>> 7dcfeafd-f287-4541-bf6f-4f1bd6ca4866 | Hiver.jpg | 105542 | >>> b44a59383b3123a747d139bd0e71d2df | | | image/jpeg >>> a4495271-01e9-454d-b995-79a89184d7e3 | Hiver.jpg | 105542 | >>> b44a59383b3123a747d139bd0e71d2df | | | image/jpeg >>> >>> when i search the file on my FS, i found it in the right binaries place i >>> configured: >>> >>> nuxeo# find / -name b44a59383b3123a747d139bd0e71d2df >>> /opt/nuxeo/data/binaries/data/b4/4a/b44a59383b3123a747d139bd0e71d2df >>> >>> but the link i have in the GUI is this one: >>> http://nuxeo:8080/nuxeo/nxfile/default/b7854e48-5698-49d8-b360-8c084aca65ac/files:files/0/file/Hiver.jpg >>> >>> And i obtain this error: >>> >>> An error occurred >>> >>> This URL isn't valid. You might want to add an outcome to your URL. >>> By writing this message, i saw an error in the path of my binaries. data >>> appears two times and i think the error could come from here. >>> I checked the path in /etc/nuxeo-dm/nuxeo.conf >>> (nuxeo.data.dir=/opt/nuxeo/data) but i really don't know why this data >>> directory appears in my binaries directory. >>> >>> >>> Thanks in advance for your help and regards, Nicolas. >>> >>> _______________________________________________ >>> ECM mailing list >>> [email protected] >>> http://lists.nuxeo.com/mailman/listinfo/ecm >>> To unsubscribe, go to http://lists.nuxeo.com/mailman/options/ecm >>> >>> >>> >>> >>> >> >> > _______________________________________________ > ECM mailing list > [email protected] > http://lists.nuxeo.com/mailman/listinfo/ecm > To unsubscribe, go to http://lists.nuxeo.com/mailman/options/ecm -- Julien Carsique, Nuxeo (Paris, France) www.nuxeo.com - The Open Source ECM Platform - www.nuxeo.org Nuxeo ECM Stack - The Java EE, scalable, standard-based ECM Platform _______________________________________________ ECM mailing list [email protected] http://lists.nuxeo.com/mailman/listinfo/ecm To unsubscribe, go to http://lists.nuxeo.com/mailman/options/ecm
