Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dtp-connect-dev] Adding Support for Filtering

Thanks Brian.

Maybe this will help clarify things.  The filtering mechanism will be the
same as the mechanism used in WTP/RDB.  The difference being where the
filter information is stored and how it is accessed by the user.  The
dialog would not be associated with the view, but would be associated with
the property dialog for a specific profile instance, i.e. the filter
settings are specific to a particular profile instance.

My understanding is that all these types of filtering were available in the
original RDB implementation and they all took affect within the catalog
loader.  Perhaps, Larry or Gilles could clarify the features of the
previous filtering mechanism.

Regards,
Rob

dtp-connect-dev-bounces@xxxxxxxxxxx wrote on 01/30/2006 09:26:17 PM:

> What kinds of filters are we talking about?
>
> I see two kinds. The kind that filter what data is loaded by the catalog
> loader and the kind that filter the information that is brought back.
>
> For example, we may have a multiple-schema database that we only want to
> see the "DBA" schema for. We set up the connection to go ahead and filter
> based on that property.
>
> But after the fact, while I'm working on the information that's pulled
> back, I may only want to look for stored procedures that start with
"SP_",
> so I add a filter that handles that.
>
> And in fact I see a third kind of filter that would completely change the
> way the catalog loader populates the information. This third type would
> possibly just bring back specific levels of items from the model. Maybe
we
> only want to see a list of databases available for a given connection and
> nothing below them. Or maybe we want to see a list of all stored
procedures
> or tables available for a given database, regardless of what schema they
> may belong to.
>
> I think the first kind (let's call it a connection filter) seems to fall
> into the category that you are proposing. And I can see the third kind of
> filter also falling into that category.
>
> The second kind of filter should simply be available from a Filters
dialog
> on the view and the user should be able to add multiple levels of filters
> like they could do in the WST viewer.
>
> I apologize if this muddies the water a bit, but I think we're dealing
with
> more than a single type of "filter" for the DBE.
>
> Thanks.
> --Fitz
>
> Brian Fitzpatrick
> Senior Software Engineer/DTP Committer
> Sybase, Inc.
> e-mail: brianf@xxxxxxxxxx
>
>
>
>

>              rcernich@sybase.c

>              om

>              Sent by:
To
>              dtp-connect-dev-b         dtp-connect-dev@xxxxxxxxxxx

>              ounces@xxxxxxxxxx
cc
>              g

>
Subject
>                                        [dtp-connect-dev] Adding Support

>              01/30/2006 08:21          for Filtering

>              PM

>

>

>              Please respond to

>              DTP Connectivity

>                   project

>              development list

>              <dtp-connect-dev@

>                eclipse.org>

>

>

>
>
>
>
>
> Hey all,
>
> Just wanted to run this proposal past you all.
>
> To the generic connection profile...
> Add properties to the DB connection profile which specify filter
> properties.
> Add a property to store then enablement state of the filter (e.g. on or
> off).
>
> To the UI...
> Expose these properties to the user through a wizard page in the new
wizard
> and a property page in the properties dialog.
>
> To the driver definition...
> Add a property to the driver definitions to store a default filter
setting
> (if possible).
> Add a property to the driver definitions to specify the default
enablement.
>
> The filter would be set on the ConnectionInfo object at the time of
> creation depending on the enablement status.
>
> We may need to improve the way property notifications are handled by the
> framework.  It would be nice if the modification notification highlighted
> specific properties that changed.  This would be necessary so the model
> could be updated in response to filter property or filter enablement
> changes.
>
> Let me know what you think.
> Rob
>
> _______________________________________________
> dtp-connect-dev mailing list
> dtp-connect-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dtp-connect-dev
>
>
>
> _______________________________________________
> dtp-connect-dev mailing list
> dtp-connect-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dtp-connect-dev
>



Back to the top