Wednesday, January 25, 2017, 4:17:10 AM, Roberto Benitez wrote: >>Also, I hope that freemarker-datasource-loader can be simplified over >>time, so it doesn't employ this many interfaces/classes. > > Currently, the only essential classes are: > 1) JdbcMetaData --A central place to store DB table/column names. > 2) TemplateSourceDao --to perform the JDBC/CRUD work
I think we shouldn't have a TemplateSourceDao inside FreeMarker. The only concern of FreeMarker is reading the templates, so only the R in CRUD. You might ask, but why not solve other operations as well, it can be convenient for some users. It's a trap FreeMarker has fell a few times in the past, and my conclusion is that it's in general not wise to address things that are outside our scope. It's a maintenance problem for one (all those little "utilities" we are dragging with ourselves, being responsible for them). Also, often we aren't even in the position to give the best solution, as the best solution depends on the application. Like here, it's likely that the user uses JPA, and has a hundred other tables that he already manipulates through that, has his company standards for it, like even some JPA hooks. I think everyone should just use his own project conventions for this, not a DAO provided by a template engine. Also we probably don't want to add yet another thing to our public API (and to the jar...), which the developers will look at, and contemplate, if they should use that, or their usual persistence solution. (We don't do anything special in there really, like we don't invalidate the related template cache entry when a row is deleted.) Components that stretch their scope too much are better be in separate jars than inside FreeMarker's core jar. > 3) DataSourceTemplateLoader -- the loader implementation. BTW, DatabaseTemplateLoader or JDBCTemplateLoader perhaps would be a more telling name. > 4) (Maybe)?) JdbcTemplateSource -- template data record including > the template content itself. This should be helpful to a client > such that no additional work should be necessary (in most general > cases) to maintain the templates (name/content)--the DAO and > JdbcTemplateSource will do the work. > > I am experimenting with the other classes/interfaces. In > particular, TemplateName and TemplateSource (which extends > TemplateName). The idea is to describe template metadata that is > more abstract that is more abstract than File, such that it could > describe a File or some database record--with the relevant data such > as name, locale. BUT, as you noted, necessitates pre-fetching data. > > > > >>My main problem with FreeMarker's TemplateLoader interface is that it >>assumes that you execute existence check, last modification query, and >>oading the actual content as 3 separate steps. While that fits how >>you deal with plain files (and I guess that's what it was modelled >>after), it doesn't fit how you do things with a database. In a >>straightforward implementation we would have 3 SQL round trips per new >>template loaded, and 2 for each up-to-date checks later. In a smarter >>implementation, and as you did it too, you can reduce the number of >>SQL operations be prefetching data into the templateSource object >>during the existence check (i.e., in findTemplateSource). As >>closeTemplateSource will be called pretty soon anyway, working from a >>such "cache" is certainly fine (because closeTemplateSource will >>invalidate it). But I don't think that you should prefetch the >>template content there, because then that will be an unnecessarily >>prefetched for template cache up-to-date checks, which is the dominant >>TemplateLoader usage in many applications. So it's sill 2 SQL-s per >>new template loaded, and 1 per template cache up-to-date checks. >>Certainly not a problem in most apps, but it's still bugs me. In >>FreeMarker 3 I definitely want to fix this be radically changing the >>TemplateLoader interface, and it's also possible that I will backport >>that solution into FreeMarker 2 (if people here will agree), though >>there it will co-exists with the traditional TemplateLoader, probably >>under the name TemplateLoader2 or something, so it's kind of messy. > > > Would the changes to the TemplateLoader be that drastic? It's a completely new interface. > Sometimes it is feasible to deprecate old/non-conformant methods > (perhaps provide defaults that rely on the new methods), which can > later be removed completely. > --Roberto -- Thanks, Daniel Dekany
