[MAGNOLIA-1981] Unable to update item due to mysqlDataTruncation exception Created: 28/Dec/07 Updated: 02/Jan/08 Resolved: 28/Dec/07 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | None |
| Affects Version/s: | 3.0.5 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Edgar Vonk | Assignee: | Boris Kraft |
| Resolution: | Not an issue | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Linux Centos 5, tomcat 5.5, jdk1.5.0_09, apache 2, mod_jk, MySQL 5 |
||
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
| Date of First Response: |
| Description |
|
If we enter too much (textual) content on a certain page we get the following exception: ERROR info.magnolia.module.admininterface.SaveHandlerImpl 19.12.2007 12:30:17 -- /: unable to update item.: failed to write property state: 55c1ea2e-ed07-4e20-b7f5-b05c720da66b/{}content
javax.jcr.RepositoryException: /: unable to update item.: failed to write property state: 55c1ea2e-ed07-4e20-b7f5-b05c720da66b/{}content: failed to write property state: 55c1ea2e-ed07-4e20-b7f5-b05c720da66b/{}content
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1197)
at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:805)
at info.magnolia.cms.core.HierarchyManager.save(HierarchyManager.java:525)
at info.magnolia.module.admininterface.SaveHandlerImpl.save(SaveHandlerImpl.java:212)
at info.magnolia.module.admininterface.DialogMVCHandler.onSave(DialogMVCHandler.java:284)
at info.magnolia.module.admininterface.DialogMVCHandler.save(DialogMVCHandler.java:181)
at sun.reflect.GeneratedMethodAccessor156.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at info.magnolia.cms.servlets.MVCServletHandlerImpl.execute(MVCServletHandlerImpl.java:96)
at info.magnolia.cms.servlets.MVCServlet.doPost(MVCServlet.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
CAUSED by:
mysqlDataTruncation: Data truncation: Data too long for column 'PROP_DATA' at row 1
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3374)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3308)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1837)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1961)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2543)
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1737)
at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2022)
at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1940)
at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1925)
It seems there is a limit in the datamodel for the storage of this content? Or maybe it is a setting in our MySQL that we need to tweak? Any help is greatly appreciated. |
| Comments |
| Comment by David Smith [ 28/Dec/07 ] |
|
You might want to look at the MySQL docs to fix this one. Specifically: |
| Comment by David Smith [ 28/Dec/07 ] |
|
It should be mentioned issues like this having to do with the configuration and implementation of magnolia should be posted on the magnolia-user list instead. |
| Comment by Magnolia International [ 28/Dec/07 ] |
|
this is not a Magnolia issue - mysql configuration (or jackrabbit) |
| Comment by Edgar Vonk [ 02/Jan/08 ] |
|
ok. thanks guys. next time I will first post the issue to the mailing list. The thing is: I did not know that it was a MySQL issue (in fact: I still don't know for sure); I thought it was a bug in Magnolia. To be honest: I think it actually is a bug. Magnolia should really do a rollback of the database transaction (updating the node) I would think? Now what happens is that the node in question becomes corrupt. |
| Comment by David Smith [ 02/Jan/08 ] |
|
Magnolia only uses Jackrabbit to store data. If there is a bug here, it's with Jackrabbit as Jackrabbit is responsible for all data storage including defining the db schema on first initialization. The advantage of using Jackrabbit is Magnolia doesn't have to know anything about the underlying data store. |
| Comment by Edgar Vonk [ 02/Jan/08 ] |
|
Ah yes, of course. Forgot about that for a minute. Thanks! |