It is currently Wed Oct 17, 2018 2:53 am


All times are UTC - 8 hours [ DST ]




Post new topic Reply to topic  [ 3 posts ] 
Author Message
 Post subject: Numberspacing and Namespacing in VISTA
PostPosted: Mon Jan 31, 2011 9:23 am 
Site Admin
User avatar

Joined: Mon Nov 01, 2010 1:58 pm
Posts: 205
Location: Seattle, Washington
Real Name: Frederick D. S. "Rick" Marshall
Began Programming in MUMPS: 15 Jun 1984
I'm importing this new discussion from Hardhats and converting it into an ongoing thread about namespaces and numberspaces. Here are the three messages so far:

===

from: Gregory Woodhouse
subject: [Hardhats] What is the formula you use for local IENs?
to: Hardhats
date: 1/29/2011 11:29 AM

I realize it's been common practice for years to assign facility local IENs using the formula

L = facility * 10^k + n

for some value of k (what is it?) A related question is simply: where is this documented? I've been aware of this practice functioning as a kind of de facto standard for years, but the obvious sources, such as the old cookbook or M-11 are no longer used.

Sent from my iPad

===

from: David Whitten
subject: Re: [Hardhats] What is the formula you use for local IENs?
to: Hardhats
date: 1/30/2011 12:57 PM

In my experience in Class III development at a local hospital
we used the value k=3 & k=6. i.e. if our facility number was
123 (which is NOT the facility number of any VA to my knowledge) then the facility variously might create files in the numbers 123000 to 123999 or might create files in the number range 123000000 to 123999999. The most common case has been k=3, but I have known some facility which used k=6.

David

===

from: Frederick D. S. Marshall
subject: Re: [Hardhats] What is the formula you use for local IENs?
to: Hardhats
date: 1/31/2011 8:13 AM

Dear Greg,

David's essentially right. Here's the rest of the story.

The value of k should be set by the file designer, but since most primary developers haven't spent a lot of time thinking about this yet, you have to use your best judgment based on the number of entries that can exist in the file under normal conditions.

First, of course, is the question of whether the entries in the file belong to the primary developer or to the adopter (site). In most files (like Patient, New Person, Drug, etc.) they belong to the adopter, so there's no reason for facilities to worry about the specific IEN assigned.

Second, is the question of whether IENs are an exposed key (such as via DINUM) or not. If the IEN literally doesn't matter (as in the Option file), then adopters and secondary developers can add entries wherever they like (as long as they don't violate the file's keys, like creating a duplicate Option name).

If the IEN is significant, then entries must either all be namespaced (as in the File file, where the entries are shared among all developers and adopters) or secondary additions must be (as in the Race file, where the primary developers own the standard entries, so sites must add their secondary entries under numberspaced IENs.

Third, the normal numberspacing rule is k=3, for small files or for stable files with permanently fewer than 1,000 entries (safe in the case of State, for example, since no matter how many states the United States adds there will probably never be 1,000). For large, stable files in which the primary developers have not yet set a value for k, secondary developers need to guess as to what k should be, and then they should share their decision publicly with all adopters to ensure we all treat each file the same way. If the adopters or secondary developers choose well, then whenever primary developers get around to setting an official value they're likely to choose the same one.

Fourth, when primary developers set values for k for their own files, they can set higher values. For example, the File Manager team set k=4 for the Dialog file to create more room for dialog entries for each package. The value of k needs to be high enough that a site whose number is 1, multiplied by 10^k, would have all of its entries placed outside the range the file would ever grow to on its own.

Fifth, for files whose IENs are significant whose number of entries is not stable, files that grow rapidly or comparatively uncontrollable, there is at present no algorithm for numberspacing established. Strategies for such files should be developed on a case-by-case basis with the help of the primary developers, because otherwise it is very easy to paint yourself into a corner and create secondary entries that collide with future primary entries.

The guidelines for secondary development, especially the rules for forward compatibility (like proper numberspacing) have not yet been written down. I have outlined and am working in earnest on that very document now and hope to have it done in a couple weeks. Since there's interest in this area, which I'm glad to see, I'll start a thread on Mumpster (mumpster.org) to discuss namespacing and numberspacing, and I'll share each guideline as I document it.

Yours truly,
Rick

_________________
Frederick D. S. "Rick" Marshall, VISTA Expertise Network, 819 North 49th Street, Suite 203, Seattle, Washington 98103, (206) 465-5765, rick dot marshall at vistaexpertise dot net
"The hidden harmony is best." - Heraclitus of Ephesus


Top
Offline Profile  
 
 Post subject: Re: Numberspacing and Namespacing in VISTA
PostPosted: Tue Feb 01, 2011 1:59 pm 
User avatar

Joined: Mon Jan 31, 2011 12:03 pm
Posts: 27
Location: Watsonville, CA (USA)
Real Name: Greg Woodhouse
Began Programming in MUMPS: 01 Oct 1992
In general, this seems to imply some formalization of the database administration process. Specifically, limits on file size need to be recorded (preferably as metadata associated with a file). Extending the dictionary of files (file 1) might be a good way to do this. If the metadata is not recorded, you're just asking for trouble.


Top
Offline Profile  
 
 Post subject: Re: Numberspacing and Namespacing in VISTA
PostPosted: Tue Feb 01, 2011 9:36 pm 
User avatar

Joined: Mon Jan 31, 2011 12:03 pm
Posts: 27
Location: Watsonville, CA (USA)
Real Name: Greg Woodhouse
Began Programming in MUMPS: 01 Oct 1992
As a general rule, I think IENs should be meaningless - or at least that's what I was going to say. But part of the problem is that Fileman allocates new IENs automatically, and this behavior is undesirable in cases where the IEN has any associated semantics, including numberspacing. File 1 is the logical repository for metadata associated with a file, so perhaps it could be extended to include a flag that would disable automatic allocation of IENs in any files where the IEN is deemed to have any significance (other than being unique). You could then add entries to these files by setting DINUM or using the IEN array in DBS calls. Another possibility would be to allow automatic allocation of IENs but restrict them to a given range. This would allow the automatic behavior while still forcing the allocated IENs to fall within the local numberspace (F*10^k + 1 through (F + 1)*10^k - 1). But frankly, I don't like this latter idea. It is much cleaner not to rely in any way on a file entry having a specific IEN. Well, with one exception: I believe that creating 1-1 (one-to-one) relationships is an entirely legitimate use for DINUM. Then again, if Fileman had a special type for 1-1 pointers that use would be unnecessary, but I digress.


Top
Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 

All times are UTC - 8 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Theme created StylerBB.net