jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Konnikov" <konni...@gmail.com>
Subject Re: jackrabbit-jcr-demo. Another idea.
Date Mon, 09 Apr 2007 19:48:41 GMT
On Mon, 09 Apr 2007 10:00:24 +0400, Jukka Zitting  
<jukka.zitting@gmail.com> wrote:

> just wanted to
> check if you had planned something like that since it would affect
> content modeling at least somewhat.

The results could be kept with different range of refining. It's possible  
to keep not only result mark but also full
information about each exact answer too.

The easiest variant is something like this:

...
mu-root/results (nt:folder)
mu-root/results/result (mu:result)

[mu:result] > nt:hierarchyNode, mix:referenceable
    - ball (LONG) mandatory primary
    - date (DATE) mandatory
    - test (REFERENCE) mandatory < 'mu:test'
    - user (REFERENCE) mandatory < 'mu:user'

More detailed variant is:

It's necessary to add mix:referenceable to mu:answer declaration, change  
declaration mu:result in this way:

[mu:result] > nt:hierarchyNode, mix:referenceable
    - ball (LONG) mandatory
    - date (DATE) mandatory
    - test (REFERENCE) mandatory < 'mu:test'
    - user (REFERENCE) mandatory < 'mu:user'

add new nodes to the tree:

mu-root/results/result/user-answers (nt:folder)
mu-root/results/result/user-answers/user-answer (mu:user-answer)

add declaration:

[mu:user-answer] > nt:hierarchyNode
    - ball (LONG) mandatory
    - question (REFERENCE) mandatory < 'mu:question'
    - selected-answer (REFERENCE) mandatory multiple < 'mu:answer'

> References in JCR are essentially two-way relations that you can
> traverse both ways, using Property.getNode() and Node.getReferences().
> This allows the reference properties to be placed on either end of the
> relation.

Imho, that doesn't guarantee consistency.

> In your content model a test "has a" topic (or topics), but there's
> nothing inherent in topic model that says it only applies to tests.

Not exactly like this. Perhaps I'm not clear in stating my thoughts. I'll  
try to change that:

Test could refer to one or more topics, exactly

Topic "has a" many tests.

Test is one of tests in the topic.

I think we should avoid unreasonable difficulties - relations like  
"many-to-many".
The model should be clear. Moreover tests would be shown by cathegories on  
page; this is only necessary to choose the
exact test.

If keeping references to topics in tests is principal, I can offer scheme  
variant, answering requirements.

[mu:test] > nt:hierarchyNode, mix:referenceable
    - title (STRING) mandatory primary
    - question (REFERENCE) mandatory multiple < 'mu:question'
    - topic (REFERENCE) mandatory multiple < 'mu:topic'

[mu:topic] > nt:hierarchyNode, mix:referenceable
    - theme (STRING)
    - test (REFERENCE) mandatory multiply < 'mu:test'

> For example it would be perfectly reasonable to use topics also to
> categorize the question packages. Instead of adding a separate "-
> packages (REFERENCE) < 'my:question-package'" property definition to
> the topic node definition, it makes more sense to add a "- topics
> (REFERENCE) < 'mu:topic'" property to the question package nodes.

I'm sure it's redundant. A package could contain questions that don't deal  
to each other. Although it's a mistake,
but theoretically it's possible.

I hope at last we would find common optimal decision.

-- 
Best regards. Pavel Konnikov

Mime
View raw message