QueryableTcProvider is not exposed as a service.

[Minto van der Sluis <mi...@xup.nl>]

Hi Folks,

While trying to solve my issues with TcManager (which is solved by now)
I tried to bypass TcManager altogether. I tried to wire my code directly
to a TcProvider. Besides the now fixed missing TcManager instance I had
another reason.

TcManager creates a service for every graph. In my environment this
could prove to be quite expensive since it a can have a large number of
graphs (production already has nearly 3000). In bypassing TcManager I
hoped to prevent this (for me) unneeded dynamic behaviour.

For one bundle I was able to circumvent TcManager by directly wiring it
to the WeigthedTcProvider. Unfortunately for another bundle this was not
enough. That particular bundle also likes to execute queries. Which is
only possible through the QueryableTcProvider. My initial thought was to
use a typecast. But is appeared the the WeightedTcPovider was not
implementing it, even though the sources (TDB) said it did.

A debug session revealed that because I was using Blueprint a proxy
object was created. Now my only option is to drop Blueprint unless ...

Shouldn't TcProvider services that also implement QueryableTcProvider
expose this interface as a service as well? Like this I could wire my
bundle to the queryable interface instead.

Regards,

Minto

Re: QueryableTcProvider is not exposed as a service.

[Reto Gmür <re...@wymiwyg.com>]

On Wed, Apr 9, 2014 at 1:27 AM, Minto van der Sluis <mi...@xup.nl> wrote:

> Reto Gmür schreef op 8-4-2014 18:23:
> > Hi Minto
> >
> > I think the best solution would be too split TcManager into two:
> > - One service component exposing TcManager
> Is the use of this TcManager mandatory?

The clerezza bylaws mandate this in § 132.


> The added value of this manager
> is being a composite over various providers with the ability to query
> over multiple providers and add access control. Other than this is see
> little added value. So if I don't need this why should I be forced to
> use it?
>
Using TcManager shouldn't add a big overhead and adds the possibility to
add virtual TcProvider. But yes, if things are well designed you can use a
TcProvider directly.



> > - One non-service component registering all graphs as individual service
> This looks like a graph registry to me :-)
>
> Who tells this registry of new or removed graphs? Currently this is
> integrated in TcManager. But if TcManager is bypassed (which is already
> possible) the registry is not kept in sync. Do we want to cope with
> this? If yes, how? Need providers become aware of the Registry?
>
Good points. Maybe we should add the possibility to add listeners to a
TcProvider.


>
> Despite al these question I do like the idea of separating the Registry
> out of the Manager.
> >
> > In your case you would disable the second component.
> I would be happier if I could just bypass TcManager. It isn't doing
> anything that helps me. Looking from the TcProvider perspective. Isn't
> is cleaner if it exposes all its abilities? Depending on the provider
> this would be one or more of the following WeightedTcProvider,
> TcProvider and QueryableTcProvider.
>
> I will give adding QueryableTcProvider as a service a try. If it works
> would this change be acceptable?
>
I see no problem in exposing this additional interface.


Cheers,
Reto

> >
> > Cheers,
> > Reto
> >
> >
> > On Mon, Apr 7, 2014 at 10:06 PM, Minto van der Sluis <mi...@xup.nl>
> wrote:
> >
> >> Hi Folks,
> >>
> >> While trying to solve my issues with TcManager (which is solved by now)
> >> I tried to bypass TcManager altogether. I tried to wire my code directly
> >> to a TcProvider. Besides the now fixed missing TcManager instance I had
> >> another reason.
> >>
> >> TcManager creates a service for every graph. In my environment this
> >> could prove to be quite expensive since it a can have a large number of
> >> graphs (production already has nearly 3000). In bypassing TcManager I
> >> hoped to prevent this (for me) unneeded dynamic behaviour.
> >>
> >> For one bundle I was able to circumvent TcManager by directly wiring it
> >> to the WeigthedTcProvider. Unfortunately for another bundle this was not
> >> enough. That particular bundle also likes to execute queries. Which is
> >> only possible through the QueryableTcProvider. My initial thought was to
> >> use a typecast. But is appeared the the WeightedTcPovider was not
> >> implementing it, even though the sources (TDB) said it did.
> >>
> >> A debug session revealed that because I was using Blueprint a proxy
> >> object was created. Now my only option is to drop Blueprint unless ...
> >>
> >> Shouldn't TcProvider services that also implement QueryableTcProvider
> >> expose this interface as a service as well? Like this I could wire my
> >> bundle to the queryable interface instead.
> >>
> >> Regards,
> >>
> >> Minto
> >>
> >>
>
>
> --
> ir. ing. Minto van der Sluis
> Software innovator / renovator
> Xup BV
>
> Mobiel: +31 (0) 626 014541
>
>

Re: QueryableTcProvider is not exposed as a service.

[Minto van der Sluis <mi...@xup.nl>]

Reto Gmür schreef op 8-4-2014 18:23:
> Hi Minto
>
> I think the best solution would be too split TcManager into two:
> - One service component exposing TcManager
Is the use of this TcManager mandatory? The added value of this manager
is being a composite over various providers with the ability to query
over multiple providers and add access control. Other than this is see
little added value. So if I don't need this why should I be forced to
use it?
> - One non-service component registering all graphs as individual service
This looks like a graph registry to me :-)

Who tells this registry of new or removed graphs? Currently this is
integrated in TcManager. But if TcManager is bypassed (which is already
possible) the registry is not kept in sync. Do we want to cope with
this? If yes, how? Need providers become aware of the Registry?

Despite al these question I do like the idea of separating the Registry
out of the Manager.
>
> In your case you would disable the second component.
I would be happier if I could just bypass TcManager. It isn't doing
anything that helps me. Looking from the TcProvider perspective. Isn't
is cleaner if it exposes all its abilities? Depending on the provider
this would be one or more of the following WeightedTcProvider,
TcProvider and QueryableTcProvider.

I will give adding QueryableTcProvider as a service a try. If it works
would this change be acceptable?
>
> Cheers,
> Reto
>
>
> On Mon, Apr 7, 2014 at 10:06 PM, Minto van der Sluis <mi...@xup.nl> wrote:
>
>> Hi Folks,
>>
>> While trying to solve my issues with TcManager (which is solved by now)
>> I tried to bypass TcManager altogether. I tried to wire my code directly
>> to a TcProvider. Besides the now fixed missing TcManager instance I had
>> another reason.
>>
>> TcManager creates a service for every graph. In my environment this
>> could prove to be quite expensive since it a can have a large number of
>> graphs (production already has nearly 3000). In bypassing TcManager I
>> hoped to prevent this (for me) unneeded dynamic behaviour.
>>
>> For one bundle I was able to circumvent TcManager by directly wiring it
>> to the WeigthedTcProvider. Unfortunately for another bundle this was not
>> enough. That particular bundle also likes to execute queries. Which is
>> only possible through the QueryableTcProvider. My initial thought was to
>> use a typecast. But is appeared the the WeightedTcPovider was not
>> implementing it, even though the sources (TDB) said it did.
>>
>> A debug session revealed that because I was using Blueprint a proxy
>> object was created. Now my only option is to drop Blueprint unless ...
>>
>> Shouldn't TcProvider services that also implement QueryableTcProvider
>> expose this interface as a service as well? Like this I could wire my
>> bundle to the queryable interface instead.
>>
>> Regards,
>>
>> Minto
>>
>>


-- 
ir. ing. Minto van der Sluis
Software innovator / renovator
Xup BV

Mobiel: +31 (0) 626 014541

Re: QueryableTcProvider is not exposed as a service.

[Reto Gmür <re...@wymiwyg.com>]

Hi Minto

I think the best solution would be too split TcManager into two:
- One service component exposing TcManager
- One non-service component registering all graphs as individual service

In your case you would disable the second component.

Cheers,
Reto


On Mon, Apr 7, 2014 at 10:06 PM, Minto van der Sluis <mi...@xup.nl> wrote:

> Hi Folks,
>
> While trying to solve my issues with TcManager (which is solved by now)
> I tried to bypass TcManager altogether. I tried to wire my code directly
> to a TcProvider. Besides the now fixed missing TcManager instance I had
> another reason.
>
> TcManager creates a service for every graph. In my environment this
> could prove to be quite expensive since it a can have a large number of
> graphs (production already has nearly 3000). In bypassing TcManager I
> hoped to prevent this (for me) unneeded dynamic behaviour.
>
> For one bundle I was able to circumvent TcManager by directly wiring it
> to the WeigthedTcProvider. Unfortunately for another bundle this was not
> enough. That particular bundle also likes to execute queries. Which is
> only possible through the QueryableTcProvider. My initial thought was to
> use a typecast. But is appeared the the WeightedTcPovider was not
> implementing it, even though the sources (TDB) said it did.
>
> A debug session revealed that because I was using Blueprint a proxy
> object was created. Now my only option is to drop Blueprint unless ...
>
> Shouldn't TcProvider services that also implement QueryableTcProvider
> expose this interface as a service as well? Like this I could wire my
> bundle to the queryable interface instead.
>
> Regards,
>
> Minto
>
>