On 22.04.10 18:27, Ян Программист wrote:
Runtime checks of transaction related locks require good thread based
performance. Currently there where problems with reflection API,
especially null arguments. If community will reject in helping me with
Java 6 support of VTI sources - than I will have
Runtime checks of transaction related locks require good thread based
performance. Currently there where problems with reflection API, especially
null arguments. If community will reject in helping me with Java 6 support
of VTI sources - than I will have to reject multi-transactional support for
th
On 22.04.10 17:25, Ян Программист wrote:
init:
deps-clean:
Deleting directory /home/webautomator/NetBeansProjects/derby/build
clean:
init:
deps-jar:
Created dir: /home/webautomator/NetBeansProjects/derby/build/classes
Created dir: /home/webautomator/NetBeansProjects/derby/build/empty
Compiling 17
Man, Java 6 compatibility is a MUST for all ORM,JDO solutions. Especially in
a case of translating XML to SQL and vise versa. Critical for table
relationship validation and SQL processing. John
Ян Программист wrote:
I propose to create a ticket in JIRA for providing *.diag (VTI)
classes conformance against Java 6. Currently compiler reports too lot
of warnings. John
What are some examples of the warnings?
Perhaps we can clean the warnings up, even if we don't change
the compilation
Said to hear that. John
Ян Программист wrote:
I propose to create a ticket in JIRA for providing *.diag (VTI)
classes conformance against Java 6. Currently compiler reports too lot
of warnings. John
Hi John
We can't compile these classes against Java 6 because the byte code
would only run on Java 5 or higher. We st
I propose to create a ticket in JIRA for providing *.diag (VTI)
classes conformance against Java 6. Currently compiler reports too lot of
warnings. John
I had some bugs while trying to configure network server for Derby
ij> connect 'jdbc:derby:repository;create=true';
ОШИБКА JAVA: java.lang.ExceptionInInitializerError
Under a tryout to create a transaction I had such exception:
Exception in thread "main" java.sql.SQLException: DERBY SQL error:
> Support diagnostic vti tables that take parameters, such as SpaceTable
> --
>
> Key: DERBY-2152
> URL: https://issues.apache.org/jira/browse/DERBY-2152
> Project:
taking a look, Dan. I committed the cleanup patch with svn
#494993. I'm resolving the issue now and will close it in a couple of days if
nothing further comes up.
> Support diagnostic vti tables that take parameters, such as Sp
[
https://issues.apache.org/jira/browse/DERBY-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463661
]
Daniel John Debrunner commented on DERBY-2152:
--
Cleanup looks good.
> Support diagnostic vti tab
issue
(d2152_vtiMappingCleanup_v1.patch), so I'm inclined to commit it. If anyone is
planning to review, please let me know; otherwise I'll go ahead and commit it
tomorrow (Wednesday) PST.
> Support diagnostic vti tables that take parameters,
[
https://issues.apache.org/jira/browse/DERBY-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A B updated DERBY-2152:
---
Derby Info: [Patch Available]
> Support diagnostic vti tables that take parameters, such as SpaceTa
n
>
> - one resolves the vti class outside the NewInvocationNode, one inside.
In an attempt to resolve these differences, the patch does the following:
1. Creates a new "init()" method for NewInvocationNode that is specifically
targeted for mapping VTI "tables" and V
tic vti tables that take parameters, such as SpaceTable
> --
>
> Key: DERBY-2152
> URL: https://issues.apache.org/jira/browse/DERBY-2152
> Project: Derby
> Is
re on
jdk6. Did you build the JDBC 4.0 drivers? I don't think you will see
these failures if you run with the JDBC 3.0 drivers on jdk6.
Your patch fixes the failure in my environment. Thank you! I have
committed it to trunk with revision 489597.
> Support diagnostic vti table
hat the attached
patch should in fact be committed, then please commit it! I would commit it
myself, but since I don't understand the two points mentioned above and since I
am not actively monitoring the lists, I don't want to make things worse...
> Suppor
attached in junit-errors.txt. I saw the
errors only once. The tests were run on Solaris 10 with Sun's JVM 1.5.0_06. I
reran the tests many times, but never saw the errors again. A timing issue,
perhaps?
> Support diagnostic vti tables that take parameters, such as Sp
getVTIClassFor* methods more
consistent with each other. That said, I'm leaving town tomorrow so I probably
won't be posting any follow-up patches until January...
Thank you for the review!
> Support
- one resolves the vti class outside the NewInvocationNode, one inside.
> Support diagnostic vti tables that take parameters, such as SpaceTable
> --
>
> Key: DERBY-2152
> URL: http://is
[ http://issues.apache.org/jira/browse/DERBY-2152?page=all ]
A B updated DERBY-2152:
---
Derby Info: [Patch Available]
> Support diagnostic vti tables that take parameters, such as SpaceTa
d2152_testing_v2.patch, to address Dan's review comments. In particular this
version of the patch separates VTI "tables" (DERBY-571) from VTI "table
functions". So the following statement:
select * from syscs_diag.space_table
will now throw error 42X05 ("table not f
nstC, ?, ?, constD))
Any thoughts/advice?
> Support diagnostic vti tables that take parameters, such as SpaceTable
> --
>
> Key: DERBY-2152
> URL: http://issues.apache.org/jira
ent patches.
I'll wait another day or so before posting a followup patch (probably on Monday
or Tuesday) in case there is more discussion re: the other issues I mentioned
in my previous comment.
Thank you for the quick feedback!
> Support diagnostic vti tabl
TABLE
but I think this should fail with a table not found exception.
>From looking at the patch I now see that the SYSCS_DIAG is not part of the
>syntax grammar, but matches the existing use for the diagnostic tables.
> Support diagnostic vti tables that take parameters, such
schema name that is passed into the bind code and then
onto the data dictionary?
> Support diagnostic vti tables that take parameters, such as SpaceTable
> --
>
> Key: DERBY-2152
>
[ http://issues.apache.org/jira/browse/DERBY-2152?page=all ]
A B reassigned DERBY-2152:
--
Assignee: A B
> Support diagnostic vti tables that take parameters, such as SpaceTa
log file. My guess is that
this is a separate bug--perhaps a privileged block missing somewhere in
the VTI code?--but I would appreciate a second opinion. For now I just
have the test running with the security manager disabled; this can be
changed when the permissions problem
Support diagnostic vti tables that take parameters, such as SpaceTable
--
Key: DERBY-2152
URL: http://issues.apache.org/jira/browse/DERBY-2152
Project: Derby
Issue Type
30 matches
Mail list logo
