hi pierre
Which I don't understand here is how the communication between the SPI and the database have to be made. I was wondering if it involved the Postgresql Persistence Manager (and in this case, if the persistence should be managed manually or if it was taken automatically into account by a SPI built-in functionality).
from my understanding there are no requirements for that communication.... so, no automatic built-in functionality with the SPI with respect to communication to databases. at least up to now.
This question make sense in the perspective for example of an implementation of the getNodeInfo method. I was thinking here of making a mapping of the node's notion from the transient perspective to the notion of database table in the persistent perspective, which means here that I don't make any abstraction of the underlying data storage (the PostgreSQL database). The problem here is that I am unable to find another solution which don't make any hypothesis on the underlying data storage. Moreover, I don't understand how to write a SPI connector which no take into consideration the datasource on which it aims to provide a JCR abstraction.
probably my jcr-view of the problem makes it hard for me to understand your problem. basically you have to define what parts of your data you want to expose as jcr-nodes and which parts as properties and in which way you want to create the hierarchy. this is something i probably can't help you with, unless i have a complete understanding of your storage. maybe somebody else....
Maybe I misunderstood the notion of SPI and its possible application as part of the writing of a SPI connector and it is what I try to know.
what would be the misunderstanding? you lost me. kind regards angela
