10/29/20 - Wayne, Cory, Brandon

Goals

- Complete the project that Cory has setup already...
	- Make the big tables smaller - Id# 1858
	- The image storage stuff - Id# 1860

- Would like to do a 3-week push

- End goal is being able to do clustering - multiple CF and multiple DB serves

- Standing Akimbo (spelling) wants to play - $10,000 - $15,000

- They want to see a real plan

- They are also willing to pay more for that clustered environment

- Going back to the database tables - currently, it looks to the database every time
	- Alan has already created a settings service
	- Extend that settings service
	- Keep all the settings based from one area

- Maybe stacking settings
	- production, test, development
	- say something like background color
	- server (data 0), site, application level, corp level, user level
	- sites may be things like production, test, development
	- sites could also be whitelabel or branding level
	- app level is like top secret, public, shop, web api sockets
	- as a side note, some of these levels may have to come later
	
- Wayne would like to combine as many of the older Application.cfm pages into one general Application.cfc (extension change and structure change)

- There is a underlying goal of getting rid requirements to switch between test and live - currently kinda messy

- Dealing with clusters... we need to move more towards session vs server or application scope variables - load balancing - the session scope is the only scope that can span multiple serves
	- In a cluster environment, you actually store the session in a database vs just in memory and in the cloud

- Putting the settings object into session... quickly look at the settings object
	- Maybe even sub rooms or sections within the settings object - shop, top secret, web api, public
	- At first, the settings object will just be the corp-wide settings
		- The setting object really needs to be the two big tables we are trying to pare down

- It works nice if we pull a query and then set those values to a physical variable. We need to get rid of the straight query.column output or use. It would be easier if we get the data and set it out to the settings object vs using a direct query.column type approach.

- We need to setup good marching orders. There will be a lot of busy work.

- We are thinking Wayne (master tech), Danny, and John M. They will each get assigned a folder and then submit branches and code back to be merged in. Not super techy, but lots of pages that will get touched. As a reminder, there are a number of sub tables.

- Lots of copying and pasting, with specific instructions.

- Wayne is planning on doing some testing for the queries.

- Wayne has a list of queries that use things like "FROM corporations" - Sublime text list

- Wayne's guys may end up helping him on the second phase where they are tweaking tables, queries, etc.

- Sub goal of trying not to make so many trips to the database - look in objects, session scope, etc.