[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Introducing the PDOM
|
Actually, we will probably need to deal with concurrency issues since it
will be possible to do read accesses to the DB for content assist,
searches, etc. while the database is being updated.
I'm hoping that an embedded database such as Derby streamlines these
things. But we'll definitely keep an eye on performance.
Thanks guys, this is great feedback so far,
Doug
On Thu, 2005-09-29 at 11:37 -0400, Alex Chapiro wrote:
> It's not so terrible as it seems to be if you take in account, that
> for
> PDOM purpose you barely need most of the features that any
> relational
> data base must implement (SQL API, transactions, concurrent access,
> security issues etc.).
>
> Recoskie, Chris wrote:
>
> >Write your own eh? I smell a technology sub-project ;-)
> >
> >___________________________________________
> >
> >Chris Recoskie
> >Software Designer
> >Texas Instruments, Toronto
> >http://eclipse.org/cdt
> >
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> >>
> >>
> >On
> >
> >
> >>Behalf Of Doug Schaefer
> >>Sent: Thursday, September 29, 2005 11:17 AM
> >>To: CDT General developers list.
> >>Subject: RE: [cdt-dev] Introducing the PDOM
> >>
> >>That's my understanding as well (and I am similarly qualified :). I
> >>
> >>
> >will
> >
> >
> >>take this through the Eclipse legal guys but my understanding is
> that
> >>
> >>
> >a
> >
> >
> >>couple of other projects are already using Derby (BIRT I think is
> >>
> >>
> >one).
> >
> >
> >>One thing I will do is make sure we can substitute the database
> engine
> >>so that people taking the CDT and having licensing issues can
> >>
> >>
> >substitute
> >
> >
> >>a different engine, or have no engine at all in which case you
> would
> >>default to the current behavior.
> >>
> >>Actually, we need this anyway in case it turns out that we can't
> get
> >>
> >>
> >the
> >
> >
> >>performance near what we'd need with Derby or SQL. Ideally, I would
> >>write my own database engine that is customized to our
> requirements,
> >>however, that's a lot of work...
> >>
> >>Thanks,
> >>Doug
> >>
> >>On Thu, 2005-09-29 at 10:40 -0400, Recoskie, Chris wrote:
> >>
> >>
> >>>As far as I know, the Apache and EPL licenses are compatible (vis
> a
> >>>vis
> >>>Xerces), but IANAL, so do your due dilligence.
> >>>
> >>>___________________________________________
> >>>
> >>>Chris Recoskie
> >>>Software Designer
> >>>Texas Instruments, Toronto
> >>>http://eclipse.org/cdt
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: cdt-dev-bounces@xxxxxxxxxxx
> >>>>
> >>>>
> >>>[mailto:cdt-dev-bounces@xxxxxxxxxxx]
> >>>On
> >>>
> >>>
> >>>>Behalf Of Treggiari, Leo
> >>>>Sent: Thursday, September 29, 2005 10:37 AM
> >>>>To: CDT General developers list.
> >>>>Subject: RE: [cdt-dev] Introducing the PDOM
> >>>>
> >>>>Hi Doug,
> >>>>
> >>>>
> >>>>
> >>>>> Absolutely. I'm currently looking at Derby, an Apache
> >>>>>
> >>>>>
> >>>embedded
> >>>
> >>>
> >>>>> SQL database that has shown some good performance.
> >>>>>
> >>>>>
> >>>>Would there any "different" licensing issues with shipping
> "Derby"
> >>>>
> >>>>
> >>>with
> >>>
> >>>
> >>>>a product that ships CDT?
> >>>>
> >>>>Thanks,
> >>>>Leo
> >>>>
> >>>>-----Original Message-----
> >>>>From: cdt-dev-bounces@xxxxxxxxxxx
> >>>>
> >>>>
> >>>[mailto:cdt-dev-bounces@xxxxxxxxxxx]
> >>>
> >>>
> >>>>On Behalf Of Doug Schaefer
> >>>>Sent: Thursday, September 29, 2005 9:45 AM
> >>>>To: CDT General developers list.; Sumit Sarkar
> >>>>Subject: Re: [cdt-dev] Introducing the PDOM
> >>>>
> >>>>Hi Sumit,
> >>>>
> >>>>This is definitely something else to consider. I know some at IBM
> >>>>
> >>>>
> >>>have
> >>>
> >>>
> >>>>this requirement as well where the source files reside on a
> remote
> >>>>machine. One option was to have the indexer run remotely. With
> the
> >>>>
> >>>>
> >>>PDOM,
> >>>
> >>>
> >>>>this should be possible and would provide functionality for all
> >>>>
> >>>>
> >>>parser
> >>>
> >>>
> >>>>based features (not just the index based ones). Since I'm using
> >>>>
> >>>>
> >SQL
> >
> >
> >>>for
> >>>
> >>>
> >>>>queries, we should be able to easily handle that on the local
> >>>>
> >>>>
> >side.
> >
> >
> >>>We
> >>>
> >>>
> >>>>would need to figure out how to package up the remote agent,
> >>>>
> >>>>
> >>>though.
> >>>
> >>>
> >>>>I'll make sure I document this as a requirement.
> >>>>
> >>>>Thanks,
> >>>>Doug
> >>>>
> >>>>On Thu, 2005-09-29 at 00:31 -0400, Sumit Sarkar wrote:
> >>>>
> >>>>
> >>>>>Hi Doug,
> >>>>>
> >>>>>In our HP Remote Development product, we are facing the problem,
> >>>>>
> >>>>>
> >>>that
> >>>
> >>>
> >>>>>"indexer" is reading the local header files (if they exist) to
> >>>>>
> >>>>>
> >>>build
> >>>
> >>>
> >>>>>the DOM. In your new architecture, if you consider a way to map
> >>>>>
> >>>>>
> >>>the
> >>>
> >>>
> >>>>>local header files with the remote (or from other location),
> >>>>>
> >>>>>
> >that
> >
> >
> >>>will
> >>>
> >>>
> >>>>>be great. That way, it will be easier for us to use the remote
> >>>>>
> >>>>>
> >>>header
> >>>
> >>>
> >>>>>files to index the remote project. I am not sure whether CDT 3.0
> >>>>>
> >>>>>
> >>>has
> >>>
> >>>
> >>>>>already this feature or not.
> >>>>>
> >>>>>Thanks,
> >>>>>sumit
> >>>>>
> >>>>>On 9/28/05, dschaefer@xxxxxxx <dschaefer@xxxxxxx> wrote:
> >>>>>
> >>>>>
> >>>>> Absolutely. I'm currently looking at Derby, an Apache
> >>>>>
> >>>>>
> >>>embedded
> >>>
> >>>
> >>>>> SQL database
> >>>>> that has shown some good performance. I'm still learning
> >>>>>
> >>>>>
> >>>SQL
> >>>
> >>>
> >>>>> but I think you
> >>>>> can merge tables together quickly. So you could create a
> >>>>>
> >>>>>
> >>>PDOM
> >>>
> >>>
> >>>>> in one
> >>>>> project, one containing all your header files for
> >>>>>
> >>>>>
> >>>example,
> >>>and
> >>>
> >>>
> >>>>> package it up
> >>>>> for delivery, and auto-merge it into the PDOM for users'
> >>>>> projects.
> >>>>>
> >>>>> I'll record it as a requirement and we'll definitely
> >>>>>
> >>>>>
> >give
> >
> >
> >>>that
> >>>
> >>>
> >>>>> a try as this
> >>>>> thing matures over the upcoming weeks.
> >>>>>
> >>>>> Cheers,
> >>>>> Doug
> >>>>>
> >>>>> "Treggiari, Leo" <leo.treggiari@xxxxxxxxx> said:
> >>>>> > Hi Doug,
> >>>>> >
> >>>>> > I think it is a GOOD idea. If we have CDT-wide
> >>>>>
> >>>>>
> >>>tool-chain
> >>>
> >>>
> >>>>> definitions,
> >>>>> > then maybe the tool-chain could provide a pre-built
> >>>>>
> >>>>>
> >>>PDOM
> >>>for
> >>>
> >>>
> >>>>> its own
> >>>>> > header files. So, you might want to consider being
> >>>>>
> >>>>>
> >>>able
> >>>to
> >>>
> >>>
> >>>>> handle
> >>>>> > multiple PDOMs for a single project.
> >>>>> >
> >>>>> > Regards,
> >>>>> > Leo
> >>>>> >
> >>>>> >
> >>>>> > -----Original Message-----
> >>>>> > From: cdt-dev-bounces@xxxxxxxxxxx
> >>>>> [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> >>>>> > On Behalf Of Doug Schaefer
> >>>>> > Sent: Wednesday, September 28, 2005 5:06 PM
> >>>>> > To: cdt-dev@xxxxxxxxxxx
> >>>>> > Subject: [cdt-dev] Introducing the PDOM
> >>>>> >
> >>>>> > Hey gang,
> >>>>> >
> >>>>> > As the next step in the evolution of the CDT DOM, I am
> >>>>> starting work on
> >>>>> > a persistence strategy that will allow us to greatly
> >>>>>
> >>>>>
> >>>reduce
> >>>
> >>>
> >>>>> the amount
> >>>>> > of parsing we do in both the indexer as well as the
> >>>>>
> >>>>>
> >>>features
> >>>
> >>>
> >>>>> that use
> >>>>> > the DOM (content assist, open decl/def, etc). The idea
> >>>>>
> >>>>>
> >>>is
> >>>to
> >>>
> >>>
> >>>>> stow away
> >>>>> > names and bindings from the DOM into a database to
> >>>>>
> >>>>>
> >>>allow
> >>>for
> >>>
> >>>
> >>>>> binding
> >>>>> > resolution and decl/ref searches to get information
> >>>>>
> >>>>>
> >>>from
> >>>
> >>>
> >>>>> this database
> >>>>> > instead of having to reparse. I am calling this
> >>>>>
> >>>>>
> >>>database
> >>>the
> >>>
> >>>
> >>>>> PDOM, or
> >>>>> > Persisted DOM.
> >>>>> >
> >>>>> > The premise is that database look-ups will be faster
> >>>>>
> >>>>>
> >>>than
> >>>
> >>>
> >>>>> building the
> >>>>> > AST for header files over and over again. That should
> >>>>> finally solve our
> >>>>> > indexer performance problems. And if not, I am making
> >>>>>
> >>>>>
> >>>it
> >>>so
> >>>
> >>>
> >>>>> that we can
> >>>>> > simply toss away the whole thing and take another tact
> >>>>> without
> >>>>> > disturbing the status-quo.
> >>>>> >
> >>>>> > I am producing a slide package on all this that I will
> >>>>> present at the
> >>>>> > CDT developer conference next month. In the meantime,
> >>>>>
> >>>>>
> >>>you
> >>>
> >>>
> >>>>> will notice
> >>>>> > code going into the CVS repository as I start trying
> >>>>>
> >>>>>
> >>>out
> >>>
> >>>
> >>>>> these ideas in
> >>>>> > optional plugins: org.eclipse.cdt.pdom.core and
> >>>>> org.eclipse.cdt.pdom.ui .
> >>>>> >
> >>>>> > If you have any questions, opinions, or even better -
> >>>>>
> >>>>>
> >>>would
> >>>
> >>>
> >>>>> like to help
> >>>>> > out, please let me know. I am certainly open to
> >>>>>
> >>>>>
> >>>opinions
> >>>
> >>>
> >>>>> that make me
> >>>>> > think this is a bad idea and save me all this work :)
> >>>>> >
> >>>>> > Cheers,
> >>>>> > Doug
> >>>>> >
> >>>>> > _______________________________________________
> >>>>> > cdt-dev mailing list
> >>>>> > cdt-dev@xxxxxxxxxxx
> >>>>> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >>>>> > _______________________________________________
> >>>>> > cdt-dev mailing list
> >>>>> > cdt-dev@xxxxxxxxxxx
> >>>>> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >>>>> >
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> cdt-dev mailing list
> >>>>> cdt-dev@xxxxxxxxxxx
> >>>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >>>>>
> >>>>>
> >>>>>
> >>>>_______________________________________________
> >>>>cdt-dev mailing list
> >>>>cdt-dev@xxxxxxxxxxx
> >>>>https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >>>>_______________________________________________
> >>>>cdt-dev mailing list
> >>>>cdt-dev@xxxxxxxxxxx
> >>>>https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >>>>
> >>>>
> >>>_______________________________________________
> >>>cdt-dev mailing list
> >>>cdt-dev@xxxxxxxxxxx
> >>>https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >>>
> >>>
> >>>
> >>_______________________________________________
> >>cdt-dev mailing list
> >>cdt-dev@xxxxxxxxxxx
> >>https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >>
> >>
> >_______________________________________________
> >cdt-dev mailing list
> >cdt-dev@xxxxxxxxxxx
> >https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> >
> >
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
