Warning: This page has not been updated in over over a year and may be outdated or deprecated.
videos:doctrine_migration
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
videos:doctrine_migration [2023/03/17 11:08] – [Video Discussion: Doctrine Migration] demiankatz | videos:doctrine_migration [2023/05/09 18:15] (current) – [Transcript] crhallberg | ||
---|---|---|---|
Line 9: | Line 9: | ||
===== Transcript ===== | ===== Transcript ===== | ||
- | // This is a raw, unprocessed transcript courtesy | + | // This is an edited version |
- | // Coming soon... // | + | So today, I wanted to talk about a project that's going to be a big part of VuFind release 10, which is migration to doctrine as a new database abstraction layer. And in order to do that, I also wanted to provide a little context about why VuFind uses a database and how we currently interact with the database so that some of the changes that are coming up will be more apparent. |
+ | |||
+ | So first of all, why does VuFind use a relational database at all? We're primarily interested in searching Solr or using external APIs. So why a database? Well, because even though VuFind relies on lots of external data, it does need to keep track of some persistent things internally. Primarily, user accounts, even if you're not using the database as the primary source of user data, if you're using an external authentication method, VuFind still has to keep track of users so that it has something that it can associate with user-generated content, which is also stored in the database. So things like tags, favorites, comments, etc. We also use the database to track search history. And there are some optional things that we can use the database for like storing sessions, or tracking record changes. As you can see, some of these things are optional. A lot of these things can be disabled if you don't actually want to track them in the database. But there are good useful reasons for having this data in VuFind in many situations. | ||
+ | |||
+ | So having established that we need a database, why use a database abstraction layer? There are a few benefits for this. One is, of course, to protect against vulnerabilities. SQL injection is a really common way of breaking into sites. And if you use an abstraction layer that forces proper escaping and so forth, you're less likely to accidentally leave some vulnerability somewhere. Abstraction layers also make cross-platform support a lot easier. So by using abstraction, | ||
+ | |||
+ | So currently, our database abstraction layer is something called LaminasDB, which used to be called ZendDB. So why did we choose this? Well, this was originally part of Zend Framework. And when we converted VuFind' | ||
+ | |||
+ | And each one has a save method that you can use to write it back into the database. Some of our custom row gateways also have methods that do all kinds of stuff like pull related things from other tables or whatever. So there' | ||
+ | |||
+ | So what am I proposing to change if we switch to doctrine? I still think we want to have two types of database classes, but I think there' | ||
+ | |||
+ | This is a lot of how the doctrine framework actually operates, is that by examining these entity classes and looking at the annotations within them, it understands how to read and write the database sort of somewhat magically. But in any case, the entities are just there to represent data and describe the structure of the database, but they do not contain action-oriented methods. You're not going to save things to the database by calling a method on an entity. You're going to pass an entity to a database service, and the service is going to do that work. And I think that by having a stricter separation of concerns here, we'll end up with cleaner code. | ||
+ | |||
+ | Additionally, | ||
+ | |||
+ | So advantages of migration. I've already talked about some of these as I've been proposing the new structure, but to highlight a few more, first of all, we have to do it. At least we have to leave LaminasDB because it's an end of life, we can't stay there forever. I think that switching to the idea of database services instead of table gateways requires us to rewrite a lot of code, which lets us move away from some very old early view find code that we still have in place that's a little bit more magical than I would like. | ||
+ | |||
+ | Just as one example, all of our controllers inherit a get table method, which they use to get access to table gateways, and it all happens with sort of low-level calls to service managers, and it's just not very explicit. I'm hoping we can move to more dependency injection that makes the relationships between the parts of our code more clear and easier to understand as we're refactoring all of this. As I said before, that's also an opportunity to use more consistent data representations in our templates. And I think this is an opportunity to greatly increase our test coverage because if we're using services to do all of our reading and writing instead of this sort of mix of doing some work on row classes that come out of table gateways and some work on the table gateways themselves, et cetera, it gets really hard to mock and simulate that. But I think we can come up with cleaner interfaces that are easier to test, and that potentially could greatly increase our project' | ||
+ | |||
+ | Of course, there are challenges to doing all this in addition to advantages, the biggest being that this is a huge volume of work. We have a lot of database code in VuFind, even though VuFind is not the most database-driven of applications. So we're going to have to rewrite a lot of code. We're going to have to test a lot of things. It's going to take time. I'm hoping that the work can also be distributed among a few people because it's a lot for one person to do. Additionally, | ||
+ | |||
+ | Perhaps we can use Doctrine' | ||
+ | |||
+ | In any case, that's sort of the high-level and maybe not so high-level look at what we have and what's coming. | ||
+ | |||
+ | I also have a link here to the pull request, which has some work in progress on getting Doctrine to work. | ||
+ | |||
+ | And though Dharma is not here today, he's also working on making some progress on that pull request. | ||
+ | |||
+ | And of course, you can contact me anytime if you have any thoughts or questions or concerns. | ||
---- struct data ---- | ---- struct data ---- | ||
properties.Page Owner : | properties.Page Owner : | ||
---- | ---- | ||
videos/doctrine_migration.1679051305.txt.gz · Last modified: 2023/03/17 11:08 by demiankatz