[Mulgara-dev] db-uri/model-uri matching

[Andrae Muys]

On 16/04/2008, at 7:08 PM, Life is hard, and then you die wrote:
> On Tue, Apr 15, 2008 at 11:28:04AM -0400, Alex Hall wrote:
>> Life is hard, and then you die wrote:
>>> The requirement that the model-uri's be "compatible" with the db-uri
>>> is becoming more and more annoying for us. We're using the new
>>> 'Connection' API's, not ItqlInterpreterBean, so in theory from a
>>> client perspective the db-uri and model-uri don't need correlation.
>>> But there's still
>>> org.mulgara.resolver.CreateModelOperation.verifyGraphUriIsRelative
>>> which is requiring the two to be related. I'd basically like to get
>>> rid of this check.
>>
>> What precisely is the format of the model URI's you would like to  
>> use?
>> The create operation does allow for non-relative URI's, as long as  
>> they
>> are opaque (e.g. "urn:model:12345").  I am using model URI's of this
>> form with the Connection API and everything works fine.
>
> In our case we'd like to keep using local:///... even though we're
> switching to rmi. But even with all rmi it's a bloody pain when you
> have some local machine name sometimes, and a different dhcp-assigned
> name othertimes, and suddenly things don't match anymore.
>
> I guess we could switch all models to something like the suggested
> urn, but if we don't have to go rename models on production (which is
> a bit of pain because it means backing up and restoring each model
> individually, and given the current problems with backups I'm not even
> confident that'll work properly) I'd be happier.
>
> As an aside, it may be a good idea then to change all examples to
> using opaque model names and to put a note in the docs for new users
> to spare them these problems.

Unfortunately these problems are going to persist until we can get  
mgr-58 finished and merged.  These problems are all a result of our  
original conflation of the concept of a model's name and a model's  
location, and while our subsequent workarounds keep things mostly  
workable, ultimately they will continue to bite us until we address  
the root cause.

Andrae

-- 
Andrae Muys
andrae at netymon.com
Senior RDF/Semantic-Web Consultant
Netymon Pty Ltd