Questions about mime-types and DatabaseReader (Berin?)

[Per-Olof Norén <pe...@alma.nu>]

Hi,
I saw Berins name in the source of DatabaseReader so i aim this mail in his direction,
though anyone who feels responsible for this piece of code is more than welcome to attend :-)

I´ve been using cocoon for quite awhile, just recently starting to actually develop/modify the components,
so if theese questions are "stupid" its possibly because of this :-)
Anyway, here goes:

1. Mime types. 
In the current implentation it is not possible to assign a database field containing the mime type to output the blob as.
In AbstractReader (superclass of DatabaseReader, naturally) following is stated
 /**
     * Get the mime-type of the output of this <code>Serializer</code>
     * This default implementation returns null to indicate that the
     * mime-type specified in the sitemap is to be used
     */
    public String getMimeType() {
        return null;
    }

If implementing a way to configure a database column to assign the mime-type, is it as simple as just overloading this method?
If doing so, does it cause implications in the sitemap behaviour (SoC)?

2. Content-lengths
Here comes the known MS buggy implementation that causes pdf files not to show up if no content-length is supplied.
At a closer inspection, one sees java.sql.Blob.length() that should return the length of the blob data. I´ve made some empirical
inspections of two drivers´: oracle and postgresql, all latest and theese two returns correct length of the blob. If one (like I did) was
to put the content-length header in the serialize method, the sitemap handling of content-length would be overkill, correct?
As a bonus, no ByteArray buffering is needed to get the content-length for a blob. I think there is a way to tell the sitemap that this component
is "self-contain" in the content-length matter? Any pointers welcome :-)

3. Getting the Blob data
This is a tricky matter since this is driver dependant. My little "research" tells me that postgresql driver does not implement the 
java.sql.Blob.getBinaryStream() in way that actually returns anything on the stream (read() == -1). However if one uses the getBytes method it does. I extended the DatabaseReader into ByteArrayDatabaseReader implementing only serialize() which uses getBytes instead of getBinaryStream. This is sortof ugly, is it possible for the DataSource to be configurable for the driver capablitity in this matter?


/Per-Olof Norén

Re: Questions about mime-types and DatabaseReader (Berin?)

[Berin Loritsch <bl...@apache.org>]

> Per-Olof Norén wrote:
> 
> Hi,
> I saw Berins name in the source of DatabaseReader so i aim this mail in his direction,
> though anyone who feels responsible for this piece of code is more than welcome to attend :-)

I did write it.

> I´ve been using cocoon for quite awhile, just recently starting to actually develop/modify the components,
> so if theese questions are "stupid" its possibly because of this :-)
> Anyway, here goes:
> 
> 1. Mime types.
> In the current implentation it is not possible to assign a database field containing the mime type to output the blob as.
> In AbstractReader (superclass of DatabaseReader, naturally) following is stated
>  /**
>      * Get the mime-type of the output of this <code>Serializer</code>
>      * This default implementation returns null to indicate that the
>      * mime-type specified in the sitemap is to be used
>      */
>     public String getMimeType() {
>         return null;
>     }
> 
> If implementing a way to configure a database column to assign the mime-type, is it as simple as just overloading this method?
> If doing so, does it cause implications in the sitemap behaviour (SoC)?

The assumption I had for this component was that all blobs in a database
column were the same.  Considering the needs I had at the time, and 90%
of the cases, I focused on supplying what I needed.  You can extend the
DatabaseReader for this purpose.  If you send in a patch that uses information
from the database for the mime-type, you can override that method there.
Do keep in mind that the getMimeType() method is called early in the pipeline
setup process, usually before the main query to retrieve the stream has
been performed.

> 2. Content-lengths
> Here comes the known MS buggy implementation that causes pdf files not to show up if no content-length is supplied.
> At a closer inspection, one sees java.sql.Blob.length() that should return the length of the blob data. I´ve made some empirical
> inspections of two drivers´: oracle and postgresql, all latest and theese two returns correct length of the blob. If one (like I
> did) was
> to put the content-length header in the serialize method, the sitemap handling of content-length would be overkill, correct?
> As a bonus, no ByteArray buffering is needed to get the content-length for a blob. I think there is a way to tell the sitemap that
> this component
> is "self-contain" in the content-length matter? Any pointers welcome :-)

If the sitemap handles the content-length, yes.  This is something we
should iron out--who's responsibility is it to handle the content-length
header?

> 3. Getting the Blob data
> This is a tricky matter since this is driver dependant. My little "research" tells me that postgresql driver does not implement
> the
> java.sql.Blob.getBinaryStream() in way that actually returns anything on the stream (read() == -1). However if one uses the
> getBytes method it does. I extended the DatabaseReader into ByteArrayDatabaseReader implementing only serialize() which
> uses getBytes instead of getBinaryStream. This is sortof ugly, is it possible for the DataSource to be configurable for the driver
> capablitity in this matter?

We should use the process that works with the broadest range of drivers.
If, according to your research, most drivers work better with the getBytes()
method, then by all means, lets modify the DatabaseReader in Cocoon.  I
wanted to use the BinaryStream because it is better to reduce the amount of
information you have in memory during one request as possible.  This allows
the system to scale better.

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org