Developer forum

Hm - we need to take a look at that...

How does this look in your settings:

(/Globalsettings/ItemTypes/MetadataSource)

Its set to Database

As far as I can tell the calls happens as soon as sources.count > 0 which is always is, perhaps it should have been > 1 instead :) 

We are experiencing the same behaviour when itemsource set to Database on 10.19.14. 
Everytime a Services.Items.GetItem is used in a frontendtemplate it fires the same select query on ItemTypeDefinitions. Which can be hunderds on certain pages.
Would be great if this could be fixed in an update.

Got it - we will look into it.

I actually thought we had deprecated database as a source. Would be interesting to understand why are you using it and not the files source?

BR Nicolai

I would prefer keeping database as a source.

To me the downsides of files is that they might not be securely saved. If a customer / developer changes items directly in prod instead of locally then the files wont be added to source control, which is high risk for us having DW running in a container. If files are chosen as a option then would also need an option to disable items management outside of local environment.

But its the sync of the items thats the issue not the source it self.

Hi Simon

Well - we just deprecated the database provider (obsolete in code) - it is already problematic as only the actual fields are stored on the table and no settings that are still stored on the XML files.

If someone changes the item type in production and you have database as source, it will also not move to source control. The issue would be the same.

If the problem is that you publish item type definitions from dev/staging to prod with missing fields compared to prod and fields in prod with data are removed - that is another situation - that can be changed and would be a better option than using database as source just to avoid that....

Hi Nikolai

My point regarding source control were that, they are at least saved to a persistent storage in form of the database, whereas files requires me to manually download the files from deployment and commit the definitions. 

The current workflow is that a frontend developer creates/manages items by logging into productions admin, make changes and then grap the added fields in the frontend project. This would leave the item defintion changes to only exist on the server on a volume. Many of our developers never start Dynamicweb locally, as our headless setup allows us to only start the frontend framework.

Hi Simon,

Won't you have the same issues if you're trying to store other definitions such as Repositories (Index, Queries, Facets), Segmented Searches, UserAndGroupType settings and even some settings currently stored in GlobalSettings? 

Since there are a few things stored in files, not just database, maybe saving Item Type definitions should follow the same process/convention.

Best Regards,

Nuno Aguiar