- From: McBride, Brian <bwm@hplb.hpl.hp.com>
- Date: Wed, 10 May 2000 21:23:01 +0100
- To: "RDF Interest (E-mail)" <www-rdf-interest@w3.org>
Sergey, I've been having a think about your PersistentModel interface. Generally, I'm feeling pretty comfortable with it. Here are a few comments and questions. 1) As you propose, Transactions seem to operate within a single model. I have multiple models in the same database, and its conceivable that an application might want to do transactional updates across more than one model. I don't have an instance of that right now, but I would prefer not to rule out the possibility. Do you think there might be a way of achieving this? One way would be to pass in a transaction object on the update calls, but that seems a bit tedious. Alternatively, perhaps there could be a call to tell two models to link there transactions. Would have to be done before any transactions had started though. Models from incompatible implementations could just refuse. 2) Your description of the API suggests a particular implementation, i.e. one where a persistent model has an in memory copy of incomplete updates and a persistent backend. I'm thinking it might be a bit of work I could avoid doing finds and the like on a mixed implementation like that. Being lazy, I'd probably try to avoid keeping in memory copies and use the database transaction mechanism directly to control the updates. 3) Could you clarify the expected semantics: If a transaction is in progress, will calls that query the state of the model reflect the incomplete updates. Calls affected are elements(), contains(), size(), find() and duplicate(). What happens when a call which creates a new model, such as find or duplicate, is made on a model which has a transaction in progress i.e. if I call find or duplicate on a model with a transaction in progress, do the models returned share the same transaction as the original? What happens if checkpoint is called on either model? What happens when an application which is unaware that the model it is dealing with is persistent, calls say, add()? As things stand the update will never be committed or rolled back. If there were a begin transaction call, then calling add()outside a transaction could be regarded as an atomic action and committed automatically. This would preserve the semantics of the model interface. 4) In my current implementation, createModel causes an update of the database. Since I have multiple models, I need to store state about them. So for me, createModel is a call that would have transaction semantics. How would you envisage this might work? Or is that my problem? 5) I have similar issues with createResource, createLiteral and createStatement. Right now, these cause database updates in my implementation. I haven't finished thinking this through though, so I'm not sure I'll stick with this approach. I'm feeling pretty comfortable you are on a good line here. regards Brian
Received on Wednesday, 10 May 2000 16:23:17 UTC