sqlite implementation

--===============5439127448882483172==
Content-Type: multipart/alternative; boundary=001a113460586199880512702964

--001a113460586199880512702964
Content-Type: text/plain; charset=UTF-8

Hi all,

I was excited to see the sqlite generator addition back in 1.8.4, as I was
struggling with the clunkiness of trying to integrate the in-game developer
documentation system for a MUD I admin for with doxygen's XML output.
Unfortunately when I took a look at what was being stored in sqlite, it
wasn't a step up from what we could get by parsing the xml, so I put the
project on hold to see if better support would turn up. It seems like
progress on the implementation has been languishing for the past year, so
I've been taking a more serious look at what information's being stored,
and how much work it'll take to push the existing implementation forward to
fit our use case (a slow process, since I haven't worked on doxygen before,
or even written any C++ in the last ~12 years...)

At first I thought this might just be a matter of extending support for
groups and pages, but as I've been getting my hands dirty I've found a
number of issues that suggest that the current implementation probably
isn't using an ideal schema or data model. For example, because we have a
lot of inheritance relationships documented, our memberdef table has 87100
total records, 70545 of which are duplicates of 3197 unique members that
differ only in rowid. I'm hoping to get a sense of whether anyone here:
- already has substantive work done on issues with this implementation that
hasn't worked its way upstream to the doxygen repo yet
- is actually using it for something non-trivial (and whether you're using
workarounds to do so)

Just hoping to get a sense of whether I am or can avoid reinventing the
wheel, and how much resistance there will be to schema changes.

Cheers,
Travis

--001a113460586199880512702964
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<div><br></div><div>I was excited to see the sqlite=
 generator addition back in 1.8.4, as I was struggling with the clunkiness =
of trying to integrate the in-game developer documentation system for a MUD=
 I admin for with doxygen&#39;s XML output. Unfortunately when I took a loo=
k at what was being stored in sqlite, it wasn&#39;t a step up from what we =
could get by parsing the xml, so I put the project on hold to see if better=
 support would turn up. It seems like progress on the implementation has be=
en languishing for the past year, so I&#39;ve been taking a more serious lo=
ok at what information&#39;s being stored, and how much work it&#39;ll take=
 to push the existing implementation forward to fit our use case (a slow pr=
ocess, since I haven&#39;t worked on doxygen before, or even written any C+=
+ in the last ~12 years...)</div><div><br></div><div>At first I thought thi=
s might just be a matter of extending support for groups and pages, but as =
I&#39;ve been getting my hands dirty I&#39;ve found a number of issues that=
 suggest that the current implementation probably isn&#39;t using an ideal =
schema or data model. For example, because we have a lot of inheritance rel=
ationships documented, our memberdef table has 87100 total records, 70545 o=
f which are duplicates of 3197 unique members that differ only in rowid. I&=
#39;m hoping to get a sense of whether anyone here:</div><div>- already has=
 substantive work done on issues with this implementation that hasn&#39;t w=
orked its way upstream to the doxygen repo yet</div><div>- is actually usin=
g it for something non-trivial (and whether you&#39;re using workarounds to=
 do so)</div><div><br></div><div>Just hoping to get a sense of whether I am=
 or can avoid reinventing the wheel, and how much resistance there will be =
to schema changes.</div><div><br></div><div>Cheers,</div><div>Travis</div><=
/div>

--001a113460586199880512702964--


--===============5439127448882483172==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
--===============5439127448882483172==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Doxygen-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/doxygen-develop

--===============5439127448882483172==--