[Mulgara-dev] Model metadata

[Robert Turner]

Thanks Paul. I guess you're right, it could have a performance impact.. 
You would need to read an extra statement (<model> <version> $version 
<#>) for each (read/write) operation and also insert an extra statement 
for a write operation. This would need to be done per model effected in 
the transaction.

Perhaps the Session or Database could hold direct references to these 
model statements. I'm assuming it would only require a few pointers per 
model to do this. As these would be "constant" statements about each 
model, you wouldn't need to do any expensive seeking/searching to locate 
them. It should only require a single read/write of a few bytes to 
update a model version.

A resolver would do it, nice idea. You would need to have access to 
create the model/set the model type though. It would prevent clients 
from being able to do this for models that are automagically discovered 
on the InterWeb.

Rob

Paul Gearon wrote:
> I've always been surprised at the lack of statements found in the 
> system model.  I just thought there'd be more to say about models 
> beyond their type.  So this actually sounds good to me.
>
> That said, I'm not so sure about the revision number on the model.  It 
> would have to be a delete/insert during a commit, which sounds messy.  
> More to the point, it sounds like it may have a performance impact.  
> Since Andrae has his head around transaction at the moment, he might 
> be the person to ask.
>
> BTW, if there IS a performance impact, it could be possible to have a 
> resolver that does some of this work separate to the store, and get 
> the update time from that.  That could be kept separate from the rest 
> of the storage system, with minimal impact.
>
> Paul
>
> On Mar 6, 2007, at 8:06 PM, Robert Turner wrote:
>
>> Hi All,
>>
>> Here's an idea for your consideration.
>>
>> I am thinking it may be useful to add some extra model metadata to 
>> the System (#) model? It currently contains statement's about model 
>> type, but it may be useful to also include statements like a created 
>> timestamp, last modified, version number etc.
>>
>> Version number metadata could be very useful for statement caching on 
>> remote consumers. For example, a client could cache statements about 
>> multiple resources and check the revision number periodically to 
>> determine if the model has changed since the last read. So instead of 
>> frequently executing queries and serializing many statements over the 
>> network, a single statement could be checked periodically to see if 
>> the cache requires purging.
>>
>> Whenever a write operation is invoked, the version number for any 
>> modified models would be incremented. The version number could also 
>> be returned to the client via the Answer API whenever a query is 
>> executed.
>>
>> Another "out-there" use of a version number could potentially be 
>> within transactions, especially if the statement store becomes 
>> journal-based. The model could be rolled back to a previous version 
>> or queried/read from as it was in a previous version (revision)... 
>> think CVS/SVN. I know this is not a new idea, but a (globally query 
>> able) version number may come in handy if it were to be implemented.
>>
>> Let me know what you think. Any ideas, suggestions, comments or hate 
>> mail?
>>
>> Thanks,
>> Rob
>> _______________________________________________
>> Mulgara-dev mailing list
>> Mulgara-dev at mulgara.org
>> http://mulgara.org/mailman/listinfo/mulgara-dev
>