CAP using your existing DB

I would absolutely not recommend that anyone follow what is being described here in this blog post.

1. They are removing HDI from CAP completely and suggesting that you manually create your modeled objects.  By removing the HDI deployer there is no automatic deployment of the DB content and therefore you introduce a manual step into any application deployment
2. What happens when you need to make changes to your data model?  Now you must manually come up with the alter statements that normally CAP and HDI would do for you?  You say CAP is not ORM - but really it is in the regard of how it should manage the transition from design time to runtime objects for you.
3. You are breaking CAP. The service layer needs to generate views to properly process. By removing the DB deployer and creating your tables yourself you are leaving out the step to deploy any views which CAP needs to generate to work properly.
4. You are storing your database credentials in a package.json. This might be OK for development testing only (I'd still make the case that default-env.json is better than package.json for even that).  But you are now using the package.json for productive deployment.  You need to now change this file for every environment you deploy into.  The credentials are insecure now.  package.json file is critical to the project will be sent to source control further exposing your credentials. This is just all kinds of wrong.

If you want to access an existing non-HDI container schema from CAP there are correct ways to do this. You should use a User Provided Service to control the credentials properly and use synonyms to access the objects. Let CAP still use HDI for the persistence it controls, however.

Once again -- PLEASE no one should ever take the approach described here!