Opened at 2009-10-16T00:04:24Z
Closed at 2010-10-15T03:18:38Z
#339 closed todo (done)
link between QueryFocus and session
| Reported by: | Ichthyostega | Owned by: | Ichthyostega |
|---|---|---|---|
| Priority: | normal | Milestone: | 0integration |
| Component: | lumieraSteam | Keywords: | session lifecycle |
| Sub Tickets: | #310, #400 | Parent Tickets: | #204, #639, #676 |
Description (last modified by )
work out how the QueryFocus can use the session / placement index for discovering scope contents. Especially make sure this works in conjunction with the session lifecycle.
Change history (7)
comment:1 by , at 2009-11-22T06:36:00Z
| blockedby: | 310, 319 → 310, 400 |
|---|---|
| Description: | modified (diff) |
| Status: | new → accepted |
| Summary: | session attaching to QueryFocus → link between QueryFocus and session |
comment:2 by , at 2010-03-22T02:01:04Z
Question: how does the other direction work, i.e. the session updating the "current" QueryFocus?
comment:3 by , at 2010-06-14T00:00:50Z
| blocking: | 204 → 204, 639 |
|---|
comment:4 by , at 2010-10-08T00:09:20Z
| blocking: | 204, 639 → 204, 639, 676 |
|---|
comment:5 by , at 2010-10-08T00:12:27Z
So basically this is reduced now to accessing the session through the SessionServices API, which is intended for internal use by Proc-Layer code. Any access here calles through the session manager pImpl, allowing to switch the current session in a quasi transactional way.
The mentioned "reverse direction" of this relation is intended to be handled by the QueryFocus following the actual access operations on the model in a semi-automatic fashion (see #676)
comment:6 by , at 2010-10-15T03:18:38Z
| Resolution: | → done |
|---|---|
| Status: | accepted → closed |
So basically model and session core (PlacementIndex) are tightly integrated now, without directly coupling the implementations.
comment:7 by , at 2025-12-25T00:00:00Z
| blockedby: | 310, 400 |
|---|---|
| blocking: | 204, 639, 676 |
| Parent Tickets: | → 204, 639, 676 |
| Sub Tickets: | → 310, 400 |
Migration MasterTickets ⟼ Subtickets-plugin
as a sideeffect of working out the QueryResolver API, this got almost completely solved. Indeed the meaning is changed, as now there isn't any active "registration" necessary anymore.