Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 336209

Summary:	saved results in OQL
Product:	[Tools] MAT	Reporter:	Iulian Dragos <jaguarul>
Component:	Core	Assignee:	Andrew Johnson <andrew_johnson>
Status:	RESOLVED FIXED	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	jaguarul
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Mac OS X - Carbon (unsup.)
Whiteboard:

Description Iulian Dragos

2011-02-03 05:31:19 EST

Build Identifier: 

There should be a way to save queries and reuse them later. There are two levels of reuse:

- save and reload later in the editor. They can be modified and executed again.
- save and refine. The saved query can be given a name, and the result set can become the target of future queries. This is somewhat handled by nested SELECT statements, but these are inefficient because the inner ones are re-evaluated every time. It would be nice to refine a search step by step.

The second use-case may be implemented either at the language level (allowing a binding form, for instance 'val myResultSet = SELECT ..', or implicitly by adding a check-box 'Operate on previous result set'. (but we'd need an undo mechanism, which is currently missing even for the plain OQL text editor).

Reproducible: Always

Comment 1 Andrew Johnson

2011-07-06 05:50:05 EDT

Another way might be to allow an OQL query to be run on a selection of objects from another query.

These could be identified using a special variable. E.g.

select * from objects ${selection} t where t.field = 2

Comment 2 Andrew Johnson

2012-11-11 12:50:19 EST

Previous OQL queries can be retrieved using the navigator view. The title is only the first line so might just read '/* Press F1 for Help */', so it would be clearer if the navigator view showed the whole query.

Comment 3 Andrew Johnson

2012-11-17 10:03:29 EST

Another small step is to ensure table results from an OQL query supplies OQL from IContextObjectSet.getOQL

This OQL should just be the select statement and a FROM OBJECTS giving the object.

Comment 4 Andrew Johnson

2012-11-21 03:26:22 EST

Some complex queries such as 
SELECT OBJECTS r from OBJECTS ${snapshot}.@GCRoots r WHERE (SELECT s FROM OBJECTS ${snapshot}.getGCRootInfo(r) s WHERE s.@type = 128) != null
weren't working.

This is for GCroots query and is selecting GC roots of a particular type. It wasn't working as the second select wasn't detected
as being context dependent (with the r in the method call), so was only being executed once.

I'll add a fix.

Comment 5 Andrew Johnson

2013-05-14 15:29:33 EDT

The reuse of queries is handled by the Navigator View - comment 2 makes it easier to use.
The save and refine can now be done by copying OQL from the result of a previous query. This works, provided there are not too many objects. If the copy is too big  (>60000 characters) then it will fail with:
"OQL statement is too big to use".
The copy OQL from an OQL also copies the column definitions. I have updated the documentation.

This should solve most of the requirements.

The 'operate on a previous result' idea doesn't work too well as the result is not reproducible, so gets
lost as soon as the new OQL statement is executed.
The binding form also has problems with reproducibility such as from the navigator view and requires more grammar changes.

I hope this solves your requirements. Please let us know how it works for you.