[TM4J-users] Re: Problems with paramaterized prepared queries + Indexing vs. Tolog Queries

[Bret C. <bre...@ya...>]

Hi Kal,

Thanks once again for your quick response.

Let me make sure I understand all of this
correctly:

Normally for tolog queries, the tolog
parser reads the topics from an XTM (or LTM)
file into Topic objects in memory,
then passes the appropriate Topic object to
the predicate implementation.

For parameterized queries, my own application
has to read the topics from the XTM file
into Topic objects, which can then be
passed to the predicate implementation.

To read topics into memory, I need to use
something like the readTopicMap() method
on p. 38 of the Dev. Guide PDF
(and also used within the IndexingExample)

At that point I could do a search of the
Topic objects in memory to find the one
to be passed in to the parametarized query.

That search could be done via one of the indices
(or, presumably, by another topic query).

This leads to two questions:

1. If the in-memory representation is out
of sinc with the XTM file. (For example,
if a new topic has been added to memory,
but not yet serialized to XTM),
on which will tolog perform the query:
the XTM file, or the in-memory representation?

2. Is it always better to use an Index
when an appropriate one is available
than a Tolog Query (for example: to find
all topics of a certain type)?

Bret

--- Kal Ahmed <ka...@te...> wrote:

> Hi Bret,
> 
> On Thu, 2004-08-19 at 19:52, Bret Cohen wrote:
> > Kal,
> > 
> > I would have been tempted to think what I've just
> > found is a bug, but my past experiences have shown
> > that the only bugs to be encountered are
> > - the flu that I can't seem to permanently fight
> off
> > - me  - bugging you about something that either
> turns
> > out not to be a problem or that has an easy
> solution
> > in retrospect. ;>
> > 
> 
> All questions and bug reports are welcome - even if
> it turns out not to
> be a bug, its a good indication of where the
> documentation needs beefing
> up, and I think this is a good case in point (this
> is a long way of
> saying "Keep asking!")
> 
> 
> > Note: Example 8.1 of Using Replacement Values, in
> the TM4J Developer's Guide PDF (p. 64)
> >       runs off of the side of the page, so it
> can't be read. When I cut & paste, I get more
> > 	of it, but it still seems like parts are missing:
> > 		QueryEvaluator qe =
> QueryEvaluatorFactory.newQueryEvaluator(tm);
> > 		PreparedQuery pq = qe.prepareQuery("select $DESC
> from descendant-
> > 		// Then later in the code, assume that we want
> to find the descendant-
> > 		TologResultsSet rs = pq.execute(new Object[] { t
> });
> > 
> > (Do I detect the descendant example I first used
> to get the ball rolling? :>)
> > 
> Thanks for the documentation bug report - I guess I
> need to reformat the
> code to get it to fit on the page.
> 
> > My confusion is over what sort of Objects may be
> passed to
> > a prepared query to represent a Topic.
> > 
> 
> This is not too clear from the documentation and
> should be - so thats
> definitely a docs bug.
> 
> > For example, in my topic map, an activity Topic
> may be associated with
> > sub-activity Topics (which are included in the
> activity).
> > I want to use the parameterized prepared query to
> allow the user to enter
> > the activity Topic for which sub-activity Topics
> are to be returned.
> > 
> > I'm trying to use the following prepared query:
> > 	select $SUBACTIVITY_FOR from
> instance-of($ACTIVITY, activity),
> > 	activity_component(%1 : includes,
> $SUBACTIVITY_FOR : included_in)?
> > 
> > The problem is that I think the query requires a
> Topic ID, a String, but
> > when I attempt to pass the String giving a Topic
> ID into the query
> > I get the following runtime exception:
> > 
> > java.lang.RuntimeException: error evaluating
> > query.org.tm4j.tologx.TologProcessingException:
> > Type mismatch in replacement of %1.
> > A Topic was expected.
> > 
> 
> Yes, you are expected to pass a Topic object in, so
> you can first find
> the Topic that the user requested (using the normal
> TM4J indexes for
> example) and then put that Topic object in the array
> of replacement
> values that you pass to the method.
> 
> Under the covers, it is the *parser* that resolves
> all of those topic
> reference types listed in the tolog language spec,
> and the predicate
> implementations receive the Topic. When you use a
> replacement value, you
> bypass the parser's string resolution part and the
> object you pass in is
> passed straight to the predicate implementation -
> hence you need to pass
> in the appropriate type of object (a Topic in this
> case).
> 
> I suppose that for completeness it might be nice if
> the replacement code
> could do a String-to-WhatIsNeeded conversion for you
> and I'll look into
> doing that as a feature enhancement, but the
> short-term solution is to
> pass in the Topic, not the topic id string.
> 
> Hope this helps!
> 
> Cheers,
> 
> Kal
> 
> -- 
> Kal Ahmed <ka...@te...>
> techquila
> 
> 



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail