[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: Project Model Improvements Re: [cdt-dev] CDT Summit Report
|
HI Mike,
On Wed, Oct 1, 2008 at 3:44 PM, Mike Kucera <mkucera@xxxxxxxxxx> wrote:
> I agree that a proper relational database is a better solution for storing
> and retrieving data than an XML file. However there may be a problem with
> going this route. Users should be able to check their entire project into
> version control, including the .project and .cproject files. (There are
> problems with sharing .cproject, but ideally it should work.) Now, if we use
> a relational db instead, I'd assume the db would be stored in some kind of
> binary file, and that may be a problem for some version control systems.
Well there are two options:
1) It's easy to dump sql databases to a text file -- but this suffers
the same readability / diffability problem of the current XML
(hence the patches on BUG to break the XML document up by storage module)
2) We could output a human readable form of the config a la VS
Currently I have an action which prints out a human readable form
of the config in diff style (i.e. shared settings are shown at the
root and folder / file level overrides show + , - , !
> So in the end we may be stuck using a text based format. I don't think XML
> is inherently evil, its just the way we are handing the XML that is clearly
> flawed. I'm not very experienced in this area but there may be better
> approaches to processing XML, like xpath queries or something. Another
> solution might be to write a SAX parser that directly builds the project
> description AST, without loading the entire DOM into memory.
Indeed. If anyone has any deep knowledge on XML processing then I'm
all ears. The fundamental problem, as Doug says, is the quantity of
data. I would argue that XML doesn't help as as the Document tree _is_
the project model currently. The current approach of replicating the
tree per thread doesn't help.
I'm all for a solution which gets up somewhere good with least effort.
However I can't see that happening in a world where the _entire_
multi megabyte model must be serialized on each and every update to
the project description.
Cheers,
James