Re: sqlite implementation

Adrian M Negreanu <[email protected]> Mon, 30 Mar 2015 14:43:15 +0300
Newsgroups gmane.text.doxygen.devel
Message-ID <CAGV5d_0ocDNK88M18JCVKv_6ueJjOxWh7sMh6qME+W6gc1LUMQ@mail.gmail.com>
--===============2171032662532637029==
Content-Type: multipart/alternative; boundary=047d7b5d5736dcbe0705127ffcd4

--047d7b5d5736dcbe0705127ffcd4
Content-Type: text/plain; charset=UTF-8

On Sun, Mar 29, 2015 at 7:50 PM, Travis Everett <[email protected]>
wrote:

> 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.
>

Hi,

I do have something on the uniqueness of the rows, but I have to dig
through my branches.
As for clients of sqlite3 backend, search.py and dynamic tooltips (through
CGI) are the current clients of the sqlite3 backend.

If you can come up with a schema that works for you, in sqlite3, I'm ok
with that.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sun, Mar 29, 2015 at 7:50 PM, Travis Everett <span dir=3D"ltr">&lt;<=
a href=3D"mailto:[email protected]" target=3D"_blank">travis.a.eve=
[email protected]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr">Hi all,<div><br></div><div>I was excited to see the sqlite gen=
erator addition back in 1.8.4, as I was struggling with the clunkiness of t=
rying to integrate the in-game developer documentation system for a MUD I a=
dmin for with doxygen&#39;s XML output. Unfortunately when I took a look at=
 what was being stored in sqlite, it wasn&#39;t a step up from what we coul=
d get by parsing the xml, so I put the project on hold to see if better sup=
port would turn up. It seems like progress on the implementation has been l=
anguishing for the past year, so I&#39;ve been taking a more serious look a=
t 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 proces=
s, 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 this mi=
ght just be a matter of extending support for groups and pages, but as I&#3=
9;ve been getting my hands dirty I&#39;ve found a number of issues that sug=
gest that the current implementation probably isn&#39;t using an ideal sche=
ma or data model. For example, because we have a lot of inheritance relatio=
nships documented, our memberdef table has 87100 total records, 70545 of wh=
ich 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 sub=
stantive work done on issues with this implementation that hasn&#39;t worke=
d its way upstream to the doxygen repo yet</div><div>- is actually using 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 s=
chema changes.</div></div></blockquote><div><br></div><div>Hi,<br><br></div=
><div>I do have something on the uniqueness of the rows, but I have to dig =
through my branches.<br></div><div>As for clients of sqlite3 backend, searc=
h.py and dynamic tooltips (through CGI) are the current clients of the sqli=
te3 backend.<br></div><div><br></div><div>If you can come up with a schema =
that works for you, in sqlite3, I&#39;m ok with that.<br></div></div></div>=
</div>

--047d7b5d5736dcbe0705127ffcd4--


--===============2171032662532637029==
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/
--===============2171032662532637029==
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

--===============2171032662532637029==--