Issues with removing db dependencies for templates

[Shannon Deminick]

I think removing the db dependency for templates is scheduled for 4.10. I'm updating the way that we look for templates, etc... in the routing to get this working with MVC and have come across a lot of issues with doing this and I think this will take quite a lot of effort.

Here's why:

* TONS of places in the codebase reference a template ID (int) which is the primary key of the database.

* The XML schema requires a template ID (int) as an attribute, we would not use this key for anything without the database

* The XML schema would need to be updated to have a templateAlias instead of templateId this is a breaking change.

* The Template class would be obsoleted and whatever legacy functionality is in there would need to be updated to maintain compatibility (if we wanted to keep it)

* INode (and the new IDocument) have a TemplateId property, this would be obsoleted and we'd have to add a new property TemplateAlias, if we change the interface this is a breaking change. Or we create a new inhertied interface like INodeWithTemplate (and IDocumentWithTemplate) but this is really ugly and hacky

Those are only a few things that I've breifly noticed and I'm sure once we attempt to do this task we will find more. I think it is a pretty deep rabbit hole especially if you want to maintain compatibility. IMO I think doing this task is a great idea but I think it should be reserved for when we release a major version and not worry about these breaking changes... we could also release this version whilst removing much of the older legacy APIs which we are in the process of migrating (thinks like INode and DynamicNode) so perhaps it would be better done in a 7.0 or 8.0 release?

Good to get some feedback on this one as it directly relates to how I'm implementing MVC and how we determine rendering engines (based on my prev post)

[Morten Bock Sørensen]

On Thursday, August 30, 2012 11:43:51 PM UTC+2, Shannon Deminick wrote:

I think it is a pretty deep rabbit hole especially if you want to maintain compatibility. IMO I think doing this task is a great idea but I think it should be reserved for when we release a major version and not worry about these breaking changes... we could also release this version whilst removing much of the older legacy APIs which we are in the process of migrating (thinks like INode and DynamicNode) so perhaps it would be better done in a 7.0 or 8.0 release?

I can definitely see the issues with maintaining backwards compatibility, and I would agree that this work would be better suited for a major release. 

As an interim solution, could it be an idea to do another thing to support xcopy deployment of templates? For example. On app start (or when selecting a template for a doctype), run through the masterpages folder, and make sure all of them have a DB entry. That way you can still create your templates from your editor of choice, and they will just be picked up by Umbraco when dropped in the folder. I think the css files have/had a similar approach?

/Bock

[Lee Kelleher]

Could we follow the same pattern as the apps/trees, with moving the 'database' to a config file? Then we'd still have IDs for templates to maintain backwards-compat.

For newly created templates, as Morten says, app-start could add those to the data-source (whether that be database or config)?

Cheers,

- Lee

--
You received this message because you are subscribed to the Google Groups "Umbraco development" group.
To post to this group, send email to umbra...@googlegroups.com.
To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/q4m_wSQKmaMJ.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Shannon Deminick]

The trees and apps are different as they never had an id reference that was used throughout the codebase.

The app startup thing can work but we have to be careful about this as it will drastically slow down app startup. Once I have the code in there to check hashes for plugin changes we can use the same to check hashes for template changes.

(sent from my Galaxy S II)

[Dan White]

Is this still planned for 4.10?

Thanks

[Shannon Deminick]

No, this has been moved to a future release at some point, the repercussions will be large and will break many things. Moving forward we actually need to change the XML schema to store the template alias and not the id, this of course is a huge breaking change. Though, i can't seem to find this task on the tracker anymore.... 

[Morten Christensen]

Here you go: http://issues.umbraco.org/issue/U4-684

Its currently assigned to v.6.0.0, but still not sure if we will actually be able to implement this because of the breaking changes you mentioned.

- Morten

On Wed, Oct 31, 2012 at 5:09 PM, Shannon Deminick <sdem...@gmail.com> wrote:

No, this has been moved to a future release at some point, the repercussions will be large and will break many things. Moving forward we actually need to change the XML schema to store the template alias and not the id, this of course is a huge breaking change. Though, i can't seem to find this task on the tracker anymore.... 

--

You received this message because you are subscribed to the Google Groups "Umbraco development" group.
To post to this group, send email to umbra...@googlegroups.com.
To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/gC8g3dB81HIJ.

[Shannon Deminick]

Its a nice to have at the moment, the db doesn't get hit on each request as the template lookup is cached... actually this wasn't the case for 4.9 and previous... but in 4.10 there should be zero db calls for rendering a page after the first hit.

[Dan White]

Got ya. So, this also means that if I create my views in Visual Studio, I also have to create the DB record?

On Thursday, August 30, 2012 2:43:51 PM UTC-7, Shannon Deminick wrote:

[Shannon Deminick]

Correct, that is why it would be really nice to have this fixed :)

The alternative is to create the db entries on app startup for new templates found, but to me this seems pretty hacky... though doable. Though before we start doing even more stuff on app startup we need to implement this: http://issues.umbraco.org/issue/U4-803 

which can be used for all of this stuff to check if things have changed, otherwise app startup will start becoming real slow.

[Barry Fogarty]

 IMO I think doing this task is a great idea but I think it should be reserved for when we release a major version and not worry about these breaking changes...

- Agreed, no way around massive breaking changes with this one.  Would be great to have this scheduled against 6.0 but makes sense to target it for the version where, as devs, we can opt for a 'Code First'  development approach.  (e.g. Document Types and Data Type definitions also decoupled from the DB).   There is definitely a lot of enthusiasm for this in the community and would be great to see the roadmap fleshed out with this in mind.