[
https://issues.apache.org/jira/browse/JCR-793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved JCR-793.
-----------------------------------
Resolution: Duplicate
resolving as duplicate of JCR-760 which has been already fixed (fix version 1.3)
> WRONG use of BLOB datatype with MySQL in node_data column of the repository
> database
> ------------------------------------------------------------------------------------
>
> Key: JCR-793
> URL: https://issues.apache.org/jira/browse/JCR-793
> Project: Jackrabbit
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.1, 1.1.1, 1.2.1, 1.2.2, 1.2.3
> Environment: MySql 4.1.16
> Reporter: mtombesi
> Priority: Critical
>
> Working with MySQL and jackrabbit ver 1.1, 1.2.1, 1.2.2 the datatype used to
> store node hierarchy data is a BLOB which only has space for 64K. Early an
> overflow occurs (just after 1800 child nodes added) and data in MySQL becomes
> corrupted, without the DBMS even raises any error on commit. It simply
> truncates the data on blob size (64K) during serialization. Thus on
> deserialization phase, the node tree is corrupted...
> A simple solution would be to use LONGBLOB for datatypes in "mysql.ddl".
> I suggest to modify the file in jackrabbit-core.jar:
> "org/apache/jackrabbit/core/persistence/db/mysql.ddl
> change:
> create table ${schemaObjectPrefix}NODE (NODE_ID char(36) not null,
> NODE_DATA blob not null)
> create table ${schemaObjectPrefix}PROP (PROP_ID varchar(255) not
> null, PROP_DATA blob not null)
> with
> create table ${schemaObjectPrefix}NODE (NODE_ID char(36) not null,
> NODE_DATA longblob not null)
> create table ${schemaObjectPrefix}PROP (PROP_ID varchar(255) not
> null, PROP_DATA longblob not null)
>
> This is a very critical problem... I lost data in production stage
> commit changes in next fixes realeased
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
