Re: cannot make indexes on long varchar?

[Rick Hillegas]

On 12/1/18 5:48 AM, Alex O'Ree wrote:

Is there a particular reason we can't do indexes on long varchar columns?


You can use VARCHAR(32672) instead of LONG VARCHAR. Then you can create 
indexes on these columns.


Hope this helps,

-Rick

Re: Derby on a docker bind mount

[Rick Hillegas]

You can maximize the verbosity of error logging by setting the following 
system property (see 
http://db.apache.org/derby/docs/10.14/ref/rrefproper26985.html):


  derby.stream.error.logSeverityLevel=0

You can also set the following system property in order to help diagnose 
which statement triggers the error (see 
http://db.apache.org/derby/docs/10.14/ref/rrefproper43517.html):


  derby.language.logStatementText=true

It looks to me as though Derby has filled up a recovery log file and 
needs to create a new recovery log file. So the actual triggering 
statement will probably be a red herring. But when Derby tries to create 
this new recovery log file, it gets a FileNotFoundException complaining 
that Derby doesn't have permission to access the following file:


  /log/log2.dat

To my eyes, that's a very strange file name. Did you really create a 
database called ? Does the following file exist:


  /log/log1.dat

The inability to continue writing recovery log records sounds like a 
fatal condition, so I am not surprised that Derby fails to boot.


Thanks,
-Rick


On 12/1/18 7:18 AM, Java CodeSmith wrote:

Hello,

I'm running a derby database and application in a docker container.

The derby version is 10.14.1.  The derby db comes up fine and works 
fine for about 1 hour.
 I can insert, delete, read, etc.  All is well until this error pops 
up.  The database is on a docker bind mount..


Windows Dockers version:  Docker Desktop version Version 2.0.0.0-win78 
(28905)


Restarting everything does not resolve the issue.  At that point it 
seems that the database is corrupted and will not start.


When the database is on a docker volume the problem does not occur.

Any ideas?  Can I put derby into a more verbose method to see exactly 
what is going wrong?


Thank you,
Paul


Wed Nov 28 00:06:10 UTC 2018 : Apache Derby Network Server - 10.14.1.0 
- (180882

0) started and ready to accept connections on port 1527

Wed Nov 28 00:06:24 UTC 2018:
Booting Derby version The Apache Software Foundation - Apache Derby - 
10.14.1.0

- (1808820): instance a816c00e-0167-57a3-2982-81b94b19
on database directory  with class loader sun.misc.Launch
er$AppClassLoader@3764951d
Loaded from file:/db-derby-10.14.1.0-bin/lib/derby.
jar
java.vendor=Oracle Corporation
java.runtime.version=1.8.0_111-8u111-b14-2~bpo8+1-b14
os.name =Linux
os.arch=amd64
os.version=4.9.125-linuxkit
derby.system.home=../derby
Database Class Loader started - derby.database.classpath=''
  Begin Error Message -
*
*
*Cannot create a new log file /log/log2.dat due to java.i*
*o.FileNotFoundException: /log/log2.dat (Permission denie*
*d)*
  End Error Message -


  Begin Shutdown Error Stack -

ERROR XSLA2: System will shutdown, got I/O Exception while accessing 
log file.
        at 
org.apache.derby.iapi.error.StandardException.newException(Unknown So

urce)
        at 
org.apache.derby.impl.store.raw.log.LogToFile.switchLogFile(Unknown S

ource)

Derby on a docker bind mount

[Java CodeSmith]

Hello,

I'm running a derby database and application in a docker container.

The derby version is 10.14.1.  The derby db comes up fine and works fine
for about 1 hour.
 I can insert, delete, read, etc.  All is well until this error pops up.
The database is on a docker bind mount..

Windows Dockers version:  Docker Desktop version Version 2.0.0.0-win78
(28905)

Restarting everything does not resolve the issue.  At that point it seems
that the database is corrupted and will not start.

When the database is on a docker volume the problem does not occur.

Any ideas?  Can I put derby into a more verbose method to see exactly what
is going wrong?

Thank you,
Paul


Wed Nov 28 00:06:10 UTC 2018 : Apache Derby Network Server - 10.14.1.0 -
(180882
0) started and ready to accept connections on port 1527

Wed Nov 28 00:06:24 UTC 2018:
Booting Derby version The Apache Software Foundation - Apache Derby -
10.14.1.0
- (1808820): instance a816c00e-0167-57a3-2982-81b94b19
on database directory  with class loader sun.misc.Launch
er$AppClassLoader@3764951d
Loaded from file:/db-derby-10.14.1.0-bin/lib/derby.
jar
java.vendor=Oracle Corporation
java.runtime.version=1.8.0_111-8u111-b14-2~bpo8+1-b14
os.name=Linux
os.arch=amd64
os.version=4.9.125-linuxkit
derby.system.home=../derby
Database Class Loader started - derby.database.classpath=''
  Begin Error Message -

*Cannot create a new log file /log/log2.dat due to java.i*
*o.FileNotFoundException: /log/log2.dat (Permission denie*
*d)*
  End Error Message -


  Begin Shutdown Error Stack -

ERROR XSLA2: System will shutdown, got I/O Exception while accessing log
file.
at
org.apache.derby.iapi.error.StandardException.newException(Unknown So
urce)
at
org.apache.derby.impl.store.raw.log.LogToFile.switchLogFile(Unknown S
ource)

Re: cannot make indexes on long varchar?

[Peter Ondruška]

Not true, you can index such columns but it does not make sense using
standard as Mikael explained. For such follow Using the luceneSupport
optional tool
.


On Sat, 1 Dec 2018 at 14:48, Alex O'Ree  wrote:

> Is there a particular reason we can't do indexes on long varchar columns?
>


-- 
Peter Ondruška

-- 
kaibo, s.r.o., ID 28435036, registered with the commercial register 
administered by the Municipal Court in Prague, section C, file 141269.

Registered office and postal address: kaibo, s.r.o., Kališnická 379/10, 
Prague 3, 130 00, Czech Republic.
https://www.kaibo.eu 

Re: cannot make indexes on long varchar?

[Mikael]

I would think it's because long columns will not work anway (half page 
size).


"Indexes

Indexes are not supported for columns defined on CLOB, BLOB, LONG 
VARCHAR, and XML data types.


If the length of the key columns in an index is larger than half the 
page size of the index, creating an index on those key columns for the 
table fails. For existing indexes, an insert of new rows for which the 
key columns are larger than half of the index page size causes the 
insert to fail.


Avoid creating indexes on long columns. Create indexes on small columns 
that provide a quick look-up to larger, unwieldy data in the row. You 
might not see performance improvements if you index long columns. For 
information about indexes, see /Tuning Java DB/."


Den 2018-12-01 kl. 14:48, skrev Alex O'Ree:

Is there a particular reason we can't do indexes on long varchar columns?

cannot make indexes on long varchar?

[Alex O'Ree]

Is there a particular reason we can't do indexes on long varchar columns?