Quantcast

sqlite implementation

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

sqlite implementation

Travis Everett
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

------------------------------------------------------------------------------
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/
_______________________________________________
Doxygen-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/doxygen-develop
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: sqlite implementation

Negreanu Marius


On Sun, Mar 29, 2015 at 7:50 PM, Travis Everett <[hidden email]> 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.

------------------------------------------------------------------------------
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/
_______________________________________________
Doxygen-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/doxygen-develop
Loading...