Derby classes purpose misunderstandings

[Ян Программист <we...@gmail.com>]

I was diving in Derby source last night, trying to find transaction related
classes. But found serious misunderstandings about comments in certain class
sources:

What kind of abstraction CompatibilitySpace provides?

Where & how should setNoLockWait(false) should be used?

I found some class, called AccessManager or something like that. Searching
didn't help to find out. So, what is the dedicated Derby Java class for
that?

I found this
http://db.apache.org/derby/javadoc/engine/org/apache/derby/impl/store/access/btree/BTree.html,
but conglomerate entity itself is a bit weird for me. Can someone help to
understand that?

I couldn't be aware of mentioning PersistentSet class (
http://db.apache.org/derby/javadoc/engine/org/apache/derby/iapi/services/property/PersistentSet.html).
Any advice about farther investigations, in focus of general data binding
strategies?

http://db.apache.org/derby/javadoc/engine/org/apache/derby/impl/store/raw/xact/NoLocking.html,
 lockContainer().
Any suggestions about using it for general purposes?

isIdle() is not static, thus means it wouldn't be referable, and should not
be referable, because:
7.1. Either table does not support transaction - easy thing
7.2. Either table do support transactions, but their is no transactions for
specific column (read: no transactions per table at mount of checking
out/request processing time*, because locking is per only row or per table;
both affect interested column)

Not clear understood what is
http://db.apache.org/derby/javadoc/engine/org/apache/derby/iapi/store/raw/Transaction.html#isPristine()
method
for...

Transaction.anyoneBlocked(). Citation from javadocs:
"Must only be called a previous local transaction was created and exists in
the context.  Can only be called if the current transaction is in the idle
state."
As already mentioned - unacceptable to check that from transaction class
instance. Defin. out of context

Purpose of TransactionFactory.noActiveUpdateTransaction() is unclear

Curious about TransactionFactory.hasPreparedXact() is near...

TransactionStatementNode.java: citation:
"/**
 * A TransactionStatementNode represents any type of Transaction statement:
 * SET TRANSACTION, COMMIT, and ROLLBACK.
 *
 */"
Not clearly understood: "SET TRANSACTION", or it is setting "TRANSACTION"
mentioned. -1 for documentation team

I haven't found any system tables for TransactionTable class. ?!

Quiesce state - what is it?

org.apache.impl.storeless.NoOpTransaction - not understood about purpose

javax.sql.rowset.spi.TransactionalWriter

BaseTableNumbersVisitor - what is that class for?

org.apache.derby.impl.sql.compile.BaseColumnNode - ?
org.apache.derby.impl.sql.compile.AccessPathImpl - ?
org.apache.derby.impl.sql.compile.AllResultColumn - ?
org.apache.derby.impl.sql.compile.BaseJoinStrategy - reflecting JOIN to
SQL/XML would combine XML tags' attributes

Not shure about how to translate ON statement equivalent to XPath queries,
but if:
    24.1. The architecture is NOT XML centric
    24.2. The architecture (maybe) RDBMS centric (when customized virtual
columns are populated from outer XML)

there is a possibbility of using XML columns for refering tag attributes, so
that would enlarge XML tree depth on binding, making possible to use XPath
for traversing JOIN equivalent

org.apache.derby.impl.sql.compile.ConditionalNode - must be constrained with
XPath condition

org.apache.derby.impl.sql.compile.ConstraintDefinitionNode - not fully clear

org.apache.derby.impl.sql.compile.HalfOuterJoinNode - while translating
XPath to SQL all RJOIN thing must be allready resolved, forming LJOIN SQL,
instead leaving that for Derby core. That would make it more near to
compiling SQL queries, relaxing database core loads; also it would enshure
data consistency by avoiding hadling of cyclic table depency

org.apache.derby.impl.sql.compile.IndexToBaseRowNode - not understood what
this class is for

org.apache.derby.impl.sql.compile.XMLTypeCompiler - good idea is to use
views tables as backend for XML type

A good idea to use *generated columns* feature of Derby to auto-generate
custom columns from _external_ ONLY  XML, not XML column type.
Good for clients, who should have only SQL interface for Derby queries, and
additional XML processing (read: after retrieving all data from result set)
wouldn't be acceptable from client side

org.apache.derby.diag.state.StatementCache - some explanation would be good
here

org.apache.derby.diag.LockTable - a rude way to find out whitch columns on
whitch tables are locked. Or not?

org.apache.derby.catalog.ReferencedColumns - ?
org.apache.derby.iapi.store.access.AccessFactory - ?
org.apache.derby.catalog.Dependable - ?
org.apache.derby.catalog.DependableFinder - ?
org.apache.derby.catalog.IndexDescriptor - ?
org.apache.derby.impl.sql.execute.StatementTrigger - ?
org.apache.derby.impl.sql.execute.TriggerInfo - ?
org.apache.derby.impl.sql.execute.UnionResultSet - would be good if that
could be used for mixing two XML results (SQL->XML) - ?
org.apache.derby.impl.sql.depend.BasicDependency - ?
org.apache.derby.impl.sql.depend.BasicDependencyManager - ?
org.apache.derby.impl.sql.compile.XMLTypeCompiler - ?
org.apache.derby.impl.sql.compile.XMLConstantNode - ?

org.apache.derby.impl.sql.compile.SubqueryNode - could be translated to
serve for XML results
Besides concreate tree structure of subquery is less critical in terms of
persistence; that is rather a responsibility of architecture, in which Derby
involved, to enshure strict persistence in replication of post-request XML
results of different SQl/XML clients

Anyone, please help me with understanding all that stuff. John