On Fri, Oct 06, 2006 at 04:16:05PM +0200, p.a.boncz wrote:
Hi all,
In PROC rpc_client() (runtime/xrpc.mx), I had changed ws_addcoll(ws, ... to ws_opencoll(ws_id(ws), ...
it should we ws_opencoll(wsid, ...)
It is wsid since this morning (see my respective checkins and earlier follow-up on this thread).
You have that, because in the query context we always have both variable 'ws' and 'wsid'.
ws_id(ws) should be called once, it asks for a unique oid. The combination of (id,int(ws)) is squeezed into a lng, and that is wsid.
As for doc_tbl(), what would work is to change its parameter to wsid; one can always get the ws with ws := ws_bat(wsid), this is done now in numerous places in pf_support.mx.
well, as said before, that's not that easy, since doc_tbl (and it's brothers/sistens) follows and API definiton that aslo returns ws --- I have not idea, how this works/is used in detail ... JanR?
Your conclusions (1), (2) and (3) are all correct.
But, Jan's suggestion to store the wsid inside the ws can also work. However, I deem it very awkward to introduce a new BAT in the ws just to retain a number. Other suggestions are to rename the ws-bat to some unique key, and then we can use that name as transaction key (=wsid). We would change the wsid type then from lng to str. Another idea is to set the head-seqbase of the ws-bat to an oid. I think the ws is accessed with fetch() only, which disregards any seqbase.
What about encoding/storing the wsid in the ws BAT's name? I'll try do do that --- seems the smallest-impact solution that could (should?) finally satisfy all sides --- I hope ... this discussion already costs far too much time and energy ... |-( Basically, call current interfaces can stay unchanged. Only ws_id() will change slightly: ws_id() checkes whether the ws BAT as already been renamed, i.e., assigend an ID; if so, it uses that one; otherwise, it assigns one nd renames the ws BAT accordingly. Thus, ws_id can be called at any time on a ws BAT, and yield the same result each time it's called on the same ws BAT.
Note that internally in pathfinder.mx there are a number of functions that just pass around an artificial wsid, and in fact a ws does not exist at all (this is the MIL document management interface e.g. shred_doc), so a number of (internal) functions in pathfinder.mx will have to stay using a wsid in their signature. They do not need a ws-bat.
But the exported functions ws_opencoll and ws_opendoc could indeed just use a ws as they did before.
I will not have time for this until next week, so if anyone feels like adventurous, he may try.
(Hopefully as a final act on this saga), I'll try to implement the above mentioned "solution" ... Stefan
Peter
-- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |