db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: 10.7.1 release dates
Date Wed, 29 Sep 2010 19:22:59 GMT
Tiago Espinha wrote:
> Hi Rick,
> I'm not really sure if it qualifies as documentation. The feature 
> itself requires no additional documentation but some of the current 
> docs need to be updated. In a previous discussion on the list [1], 
> Kathey identified at least one spot that requires an update:
> "For both driver and DataSource access, the database name (including 
> path), user, password and other attribute values must consist of 
> single-byte characters that can be converted to EBCDIC. The total byte 
> length of the database name plus attributes when converted to EBCDIC 
> must not exceed 255 bytes. You may be able to work around this 
> restriction for long paths or paths that include multibyte characters 
> by setting the derby.system.home system property when starting Network 
> Server and accessing the database with a relative path that is shorter 
> and does not include multibyte characters."
> Right now pretty much all of this is false. The arguments don't have 
> to be single-byte characters and while the length is still 255 bytes, 
> this may or may not be equivalent to 255 characters (UTF-8 is 
> variable-length).
> Should I file a JIRA issue for this?
Hi Tiago,

Yes, please.

> Thanks,
> Tiago
> [1] - http://old.nabble.com/Database-name-length-tt29691419.html
> On Wed, Sep 29, 2010 at 7:22 PM, Rick Hillegas 
> <rick.hillegas@oracle.com <mailto:rick.hillegas@oracle.com>> wrote:
>     I have filled in dates for the 10.7.1 release, dropping the first
>     RC back to mid-November to give us time to catch our breath after
>     vetting 10.6.2:
>     http://wiki.apache.org/db-derby/DerbyTenSevenOneRelease  I have
>     added a 2 week slot for buddy-testing. I hope that we can wrap up
>     the user documentation by the end of October. That will help buddy
>     testers understand the features they need to verify. The following
>     features need user documentation:
>     o Definer's rights
>     o TRUNCATE TABLE (will need a little extra verbiage after Eranda
>     finishes implementing the optional clauses)
>     o Plan Exporter (needs a disclaimer that this is a preliminary
>     version of the tool, whose user experience may change after we get
>     feedback from the field)
>     The DRDA UTF-8 support is also marked as needing user
>     documentation. Is that really true? If so, could someone open a
>     separate JIRA describing the changes needed?
>     Thanks,
>     -Rick

View raw message