I'm opening an issue here for starting thinking about this before we can discuss it in person. I think we should consider using a "real" DB engine in order to allow for efficient and flexible searches. If we want to implement it manually we probably will loose too much time reinventing the wheel and probably we wouldn't achieve the same functionality.
sqlite3 seems to be a good candidate, no need for complex setup and has python bindings. In addition it implements full text search.
As our use case is fairly simple, I think we can have just one table with the relevant fields for identification (bibtex label) and searching (author, year, title, maybe conference), and an additional "fullentry" text field where we store the bibtex entry. I might be able to code a prototype in the next days.
davvil
commented
6 years ago
I'm opening an issue here for starting thinking about this before we can discuss it in person. I think we should consider using a "real" DB engine in order to allow for efficient and flexible searches. If we want to implement it manually we probably will loose too much time reinventing the wheel and probably we wouldn't achieve the same functionality.
sqlite3 seems to be a good candidate, no need for complex setup and has python bindings. In addition it implements full text search.
As our use case is fairly simple, I think we can have just one table with the relevant fields for identification (bibtex label) and searching (author, year, title, maybe conference), and an additional "fullentry" text field where we store the bibtex entry. I might be able to code a prototype in the next days.
What do you think?