openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick" <michael.d.d...@gmail.com>
Subject Re: [jira] Created: (OPENJPA-740) In MySQL use LONGBLOB, MEDIUMBLOB etc.. when needed, cause BLOB only holds 64kb of data.
Date Wed, 08 Oct 2008 14:22:06 GMT
Hi Simone,

My first instinct was to point to the mapping guidelines provided for JDBC
[1]. Then I realized how small a MySQL BLOB really is [2] and
now I agree. MEDIUMBLOB seems like a good compromise for MySQL. It's really
just a matter of changing the blobTypeName variable in MySQLDictionary.java,
if you want to submit a patch feel free, otherwise I'm happy to make the
change.

-mike

[1] http://java.sun.com/j2se/1.5.0/docs/guide/jdbc/getstart/mapping.html
[2] http://dev.mysql.com/doc/refman/6.0/en/storage-requirements.html


On Tue, Oct 7, 2008 at 6:22 PM, Simone Gianni <simoneg@apache.org> wrote:

> Hi Michael,
> yes, I worked it around that way, but still think this is somehow a bug.
> I'll try to patch the MySQLDictionary to generate proper (read: mysql
> non-standard) column types based on the length when it comes to
> TEXT/CLOB/BLOB. I think I can find time to do it on Thursday.
>
> Thanks,
> Simone
>
> Michael Dick wrote:
> > Hi Simone,
> >
> > Patch submissions are always welcome :-), but there is a fairly simple
> > workaround.
> >
> > All (or nearly all) the DBDictionary attributes can be changed in your
> > configuration. You should be able to work around this problem by adding
> the
> > following to persistence.xml :
> > <property name="openjpa.jdbc.*DBDictionary*"
> > value="mysql(blobTypeName=MEDIUMBLOB)" />
> >
> > I haven't tested it out, I'll try to take a closer look tonight or
> tomorrow
> > morning.
> >
> > Best Regards,
> >
> > -mike
> >
> > On Tue, Oct 7, 2008 at 5:26 PM, Simone Gianni <simoneg@apache.org>
> wrote:
> >
> >
> >> Hi all,
> >> I can try to patch the code and provide a patch by myself, I'd just like
> >> to know if this bug is "real" or if I'm missing some important
> >> workaround that would make this bug (and the patch) useless.
> >>
> >>
> >> Thanks,
> >> Simone
> >>
> >> Simone Gianni (JIRA) wrote:
> >>
> >>> In MySQL use LONGBLOB, MEDIUMBLOB etc.. when needed, cause BLOB only
> >>>
> >> holds 64kb of data.
> >>
> >>
> ----------------------------------------------------------------------------------------
> >>
> >>>                  Key: OPENJPA-740
> >>>                  URL:
> https://issues.apache.org/jira/browse/OPENJPA-740
> >>>              Project: OpenJPA
> >>>           Issue Type: Improvement
> >>>           Components: sql
> >>>     Affects Versions: 1.2.0
> >>>             Reporter: Simone Gianni
> >>>
> >>>
> >>> When a column is annotated as a BLOB of using @Persistent to use
> >>>
> >> streaming blobs, and the underlying database is MySQL, OpenJPA will
> create a
> >> column of type BLOB. Unfortunately, in MySQL a BLOB column can hold a
> (vary)
> >> limited amount of data, while (especially when using streaming blobs)
> the
> >> user would probably expect it to hold a large amount of data.
> >>
> >>> Also adding the @Column annotation and specifying a size bigger than
> what
> >>>
> >> a BLOB column in MySQL can hold, OpenJPA still creates only a BLOB
> column.
> >>
> >>> I think OpenJPA should be able to create the proper column type
> depending
> >>>
> >> on the @Column annotation if present, or otherwise default at least to a
> >> MEDIUMBLOB to preserve cross-database compatibility as expected.
> >>
> >>> The simplest patch i can think of is setting blobTypeName="MEDIUMBLOB"
> in
> >>>
> >> the MySQLDictionary constructor.
> >>
> >>> Otherwise, overriding the getTypeName to properly parse the length and
> >>>
> >> return the correct BLOB/TEXT type for mysql.
> >>
> >>>
> >> --
> >> Simone Gianni            CEO Semeru s.r.l.           Apache Committer
> >> MALE human being programming a computer   http://www.simonegianni.it/
> >>
> >>
> >>
> >
> >
>
>
> --
> Simone Gianni            CEO Semeru s.r.l.           Apache Committer
> MALE human being programming a computer   http://www.simonegianni.it/
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message