[Bug 622] New: Mountpoints: Do they persist or don't they?

http://helma.org/bugs/show_bug.cgi?id=622

           Summary: Mountpoints: Do they persist or don't they?
           Product: Helma
           Version: 1.6.1
          Platform: All
               URL: http://zenpsycho.com/TestBug.zip
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Database Layer
        AssignedTo: helma-dev@...
        ReportedBy: breton.slivka@...


At the included url http://zenpsycho.com/TestBug.zip is a test helma app whose
root prototype contains 2 actions: add and main.  The main action will return
an error the first time you run it, since the main action is looking for an
object which does not yet exist.  

the add action adds an object to a collection. After visiting the add action,
return to the main action, and it will properly display a property of the
object which was just added. Restart the application, and visit the main action
again: You should see the original error, as though the object that was added
never existed.

The application uses the built in xml DB and is structured as follows:

root - > homepage = mountpoint ( HomePage )
HomePage - > pages = mountpoint ( PageManager )
PageManager - > _children = collection ( Page )

the "add" action adds a page to "pages". The built in xml DB as a result
persists the page object, and its parent "pages", but not "homepage". the xml
files produced are 0.xml, 1.xml, 3.xml, and 4.xml.    2.xml is curiously
missing, and the parent idref in 3.xml is the word "homepage", not a number.

this perplexed me for a while, as it made me think there was a bug in Helma
that prevents it from persisting mountpoints.  Others I've shown this to
thought it was a bug specifically with the built in DB. But today, I'm
beginning to think that neither is the case.

Today, I've come to understand mountpoints differently. It looks to me like a
mountpoint mapping is meant to be essentially the same as an object mapping
with one critical difference: An object is persisted, and a mountpoint is
transient, and that is it.   mountpoints behave exactly the same with the built
in DB as they do with the SQL DB, however, the consequences are very different.

In an SQL DB, the fact that mountpoints are not persisted is not an issue,
since all collections are constructed dynamically from database queries defined
in type.properties. However, in the built in DB, the entire object graph must
be in tact and persisted or Helma will not be able to reconstruct it. The
transient mountpoints form a gap in the persisted chain, leading to very
different and unexpected behavior compared to the SQL mapped behavior of helma.
One can fix the TestBug.zip by changing all the mountpoint mappings to object
mappings.

However, despite this line of thinking, the TestBug.zip app features a
mountpoint that is persisted, and another mountpoint that isn't persisted.
Which raises the question of what is the intended behavior of mountpoint vs.
object? Are mountpoints meant to be persisted or not?

 It seems to me that this app demonstrates a bug either way you look at it,
since the persistence behavior is inconsistent. Mountpoints should either
always persist, or never persist. And if the intent was that mountpoints should
not persist, Helma should not attempt to persist a mountpoint's children
either.


--
Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Helma-dev mailing list
Helma-dev@...
http://helma.org/mailman/listinfo/helma-dev