Re: Getting article aid (giving or not givingpubid) via the title

In article <bjnitv$ajf$1-111RdWWlOxkOkXtL6OYfHgC/[email protected]>, "Jason Judge" <[email protected]> wrote:
>"mikespub" <[email protected]> wrote in message
>news:[email protected]
>> >...
>> The search function exists, which is why I recommended it as a first
>> approach. Now if there is a valid case for retrieving an article by
>exactly
>> matching a specific field (and both you & Jason seem to say there is),
>> then we can easily add that as part of the standard articles API as well.
>
>I am wondering if there is scope for a more generic hooked module to provide
>alternative references to items in modules? To my mind, linking items of any
>type to data maintained or updated from an external system could use this
>type of thing - and that could apply to any type of item. It is almost like
>(well, very like) using an alternative set of item IDs layered over the top
>of the existing data.
>
The problem is that only the item IDs are guaranteed to be unique in all 
cases. If for a particular site you decide that (title + pubtype id) should
be unique in articles, or that (name) should be unique in the example
module, or ..., then you can provide access based on those alternatives,
and enforce their uniqueness in the database as well.

But what may apply in your case will not apply for others, so I don't
see how we could easily turn this into a common feature based on
existing fields.

The other approach, where a separate table would keep track of the
link between (internal) module items and (external) references,
comes very close to what I had in mind with the kbase discussion :
have a (base + id) on the hand, and a (module + itemtype + itemid)
on the other hand, so that e.g.

kbase 123 <-> articles 7 345
kbase 124 <-> articles 7 765
..
product "PIPPO PC SERVER" <-> articles 9 210
product "PIPPA PC CLIENT" <-> articles 9 987
..

I call it the xlink module - at least in my head... :)

Mike.