Hi Mansur,
> (class +DEnt +Entity) #Ancestor for project data classes
> (rel id (+Key +String))
> (rel dsc (+Idx +String))
>
> (class +Folder +DEnt)
> ..
>
> (setq +User '(+DEnt))
> (extend +User)
> (rel nam (+String)) # Full Name
> ..
>
>
> Now I try to use iter, scan and collect:
>
> : (collect 'id '+Folder)
> -> ({47} {32} {40} {31} {6})
> Seems OK
>
> : (scan (tree 'id '+Folder))
> -> NIL
>
> : (iter (tree 'id '+Folder))
> -> NIL
>
> Why NILs here?
This seems to be all correct.
The functions 'scan' and 'iter' are low-level, accessing explicitly the
tree structures.
I assume that the objects '{47}' etc. are of class '+Folder'. The
indexes are defined for the super class. 'collect' knows about that, and
returns the expected objects, while 'scan' and 'iter' simply output the
contents of the index trees for '+DEnt'.
> Then I tried with my ancestor class
> : (iter (tree 'id '+DEnt))
> {47}
..
OK, this is also as expected.
> Then I put "USER1" to id of '+User object
> : (collect 'nm '+User)
> -> ({20} {26} {25} {30})
> : (put!> '{20} 'id "USER1")
> -> USER1
> ...
> : (put!> '{26} 'id USER1)
> -> USER1
> #I think it should produce error "Not unique" ?
This is a typo. You actually put NIL as the value, because 'USER1" isn
not quoted and is probably a symbol with value NIL. Putting NIL as a
value, however, means to clear it.
Besides, the 'put!>' method will actually never produce an error if a
non-unique value conflicts. Again, this is handled on a higher level,
typically in the GUI which implicitly calls the 'mis>' methods. The
'+E/R' prefix class handles this automatically.
If a non-unique value is put forcibly for a relation that has a unique
key, the second put will simply override the first one.
> So, do these results mean I should not use relation inheritance or
> is it bug?
No, you class hierarchy looks perfectly OK.
Just one question. Why did you write
> (setq +User '(+DEnt))
and not
(class +User +DEnt)
Was it just for informal reasons, as the example is picked from a larger
context?
Anyway, the effect is, as far as the above example is concerned, the
same.
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
