feedback to Daniel and Jeroen's great adventure rebuilding carmel database

[adriatic]

Item 1 - starting at :point_up: April 5, 2017 1:20 PM

This start immediately diverges from my path indicated here, and likely will result with more and more issues I will encounter in this feedback document. Rather than referring to too many dispersed hints why to use VS 2017 as the development tool (at least in the initial phase used to verify that Jeroen has the same bits as I do) I just wrote one common document explaining them.

This section addresses the Gitter discussion up to :point_up: April 5, 2017 1:30 PM

I would care to know why did @JeroenVinke decide to avoid this VS based approach, by the way.

[adriatic]

Skipping the whole discussion on where should the arrow point to, with the immediate comment to :point_up: April 5, 2017 1:30 PM - referring you to my comment where I had a similar suspicion.

This arrow discussion ends here :point_up: April 5, 2017 3:16 PM - and just like you two, I had a blast reading it 😄

Conclusion: we should define a standard operating procedure for sources of our files local / CDN and stick to this, so that when a new app (like carmel-api is created from scratch - all parts should be added in that standard way.

With this :point_up: April 5, 2017 3:16 PM in mind, I hope that you are using the KendoUI SDK associated with our free license (see bitwarden)

Also, I will not wait for Rob to create CDN for files we use and do it myself for aurelia-tools organization (which in my mind always include aurelia-ui-toolkits)

[adriatic]

Item 2 - :point_up: April 5, 2017 3:49 PM

@JeroenVinke is by far best positioned to make the toolbar decision - I took the screenshot introducing toolbar as a quick hint on how to manage the actions taking part inside the carmel editor frame

Now, as there is a real focus on what should be built, we can discuss all details as they pop-up. As an example, I am very much in agreement with :point_up: April 5, 2017 3:52 PM

[adriatic]

Item 3 - KendoUI controls behavior (:point_up: April 5, 2017 3:53 PM to :point_up: April 5, 2017 3:59 PM)

Since this initial carmel app creates metadata for the KendoUI catalog, it would be really silly to use some different UI toolkit. We should also think about easy creation of the carmel-materialize version - and then use all of this data for building aurelia compendium and for amazon compendium

[adriatic]

Item 4 - on database recreation :point_up: April 5, 2017 4:00 PM

I do not like database (unlike Daniel), or better to say never felt the need to learn it to the point where I am able "programming with sql" comfortably. Given that carmel has very simple database, I went for the code first approach and initially had two applications: carmel-api (which is "headless") and "database creator" aspnet web app using razor to create the UI that would suffice to create and maintain the actual database consumed by carmel-api.

A lot later, it dawned on me that this is really silly approach and that carmel-fe should be able to deal with database changes, given that we have (will have) role based authorization and plan to support adding new components and certainly new samples for existing components (all of these will change the schema). We have not even discussed this additional role for carmel-fe - and as I was not sure what would two of you say on that additional work I left carmel-db app (as defined by carmel.csproj document - this is the only document that really describes this app and we need to make sure it is being used for that purpose)

Now, focusing on :point_up: April 5, 2017 4:00 PM:

The section Step 2: Create the database itself. explains (unsuccessfully it seems):

Assume that the database already exists, so this description handles any step after the first. Thus the reason for creating the database would be the change in the initial Carmel models content.

The meaning of this is that the following steps describe the process after the initial database was created once - which would be the case when Jeroen followed my VS 2017 based process and then, having it done and verified as correct, would desire to make changes as needed.

I suspected that Jeroen would dislike my approach of starting with the local copy of the "catalog content" descriptor, which is used as the input to this node application and then take the output file and manually insert it into CatalogContextSeedData.cs class - but I left if in place so anyone can recreate the app as it is today.

Regardless of that, running dotnet ef database update is not the way to go as the ef part is far from complete and there is no end to problems following that path. It is however possible that my experience with ef core is not current any more - but for the sake of simplicity and saving time, I would recommend to do this:

1. Delete the current instance of the CarmelDb - which would be created when once runs the Visual Studio 2017 solution defined with Carmel.sln (see this comment as the explanation). Use VS SQL Server Object Explorer (as decribed in Why VS 2017 - and not cli) to delete that database.
2. Build a new version of the database as decribed two paragraphs above this.

This should address your discussion starting :point_up: April 5, 2017 4:03 PM

I would suggest to first rebuild the app the way I did - and then go different ways if needed. I took a lot of effort to write this (and other related) document(s), because I wanted to explain what I did and why with the intent to simplify future collaborators. I would like to be taught of a better way to do this - if you know of a better way. A simple statement "I do not like Visual Studio" will not suffice to change my current position, though 😄.