Page History

...

• PA: Earned premium is not really about one's data set, but about EP within a certain timebound. To get this, we take earned premium/months covered. This is very basic, and data set will never be one like this. 
• PA: Working with SQL - hard to utilize parameters without an extremely advanced client. I have start dates and end dates, and strings, but they are parameterized when actually used.
• PA: We begin by running a setup command and creating a temp table, called Temp Auto & Earned Premium. Begin calculating group 1, group 2, group 3, only 1 creates the table, next ones insert into that table.
• Extraction for EP comes down to selecting sum from temp table. Teardown at end is drop of 1 table. 8 columns - EP is first column. Second part - not only earned premium but EP by coverage - column by column. So breakdown will expand significantly over time.
• KS: current path is sufficiently robust to implement this. PA: this is actually a single select statement (KS pointed out not a single select to implement the whole thing).
• KS: Line 14 - this is a create table statement not a select statement. We have to recognize HDS schema request as a select statement. 
• PA: What we need to do is take these commands, break them down, and separate parse them into objects - e into queries with semicolons.
• KS: This will not work - won't come up as a select statement. We therefore need to break it up into script, yes?
• JM: No, will be fine -after tokenizing this each token represents a query, within that larger query. Show the first token within those larger tokens - if it's select, it will do something, but it doesn't matter, because it's the responsibility of the query writer to identify the two schemas in question.
• JM: All scripts assume their default schema is going to be openIDL_ep - we only specify schema for occasions that involve reaching out to base schema.
• PA: But when we're doing the create statement for EP... we should go openIDL_ep?
• JM We leave it blank. Because it is so common to reference EP schema
• PA: I'm talking more when I create the database.
• JM: but in creating base schemas we want to specify schema name, absolutely. (KS: this happens outside of extraction execution. PA: but pivotal to do this in setting up HDS).
• KS: The default schema then is the EP schema, therefore it doesn't have to be mentioned anywhere even though it can be but doesn't have to be. 
• PA: It may be that we start to have some persistent more advanced tables in EP - recurring structures.
• JM: This proves our point and this is exactly what this code tends to look like in terms of business logic.  From a pattern perspective, there is different logic for 1 2 3 4, correct?
• PA: Correct. We process records differently depending on when they fall in the year vs. where they are extracted.
• JM: This is a source of confusion - i.e., what is the difference between line 25 and line 34. (He got clarity on this).
• JM: This demonstrates the case of being able to make intermediate tables. For people who have to read it comprehensibility is a must.
• PA: for For EP - could make more sense to utilize a function and build it differently. 
• JM: for For scalability & modularity, the desire for functions explains the need for EP schema separation (HDS)from the HDS/base schema. It points to repeat question of should this be in the extraction patterns or DB definition?
• PA: For auto, with earned premium, if we have this, and the corresponding function exists in the architecture, we can have a good test set , we can establish and a high level of confidence level that functions are working that the function works correctly.
• JM: single function business point for every business rule. Functions should be defined in either Business rule management is critical here. One of the requirements from business people: they have to be able to manage these rules and comprehend them in a useable way. If we can start getting acute granularity - 1:1 on requirements and functions - there should be a single functional entry point for every designated business rule. This is incredibly powerful re: the scalability of human comprehension. Functions should be defined in either the base schema or EP schema but not borne buried into extraction patterns. They are too stable across time.
• PA: We're going down an interesting path that will put us in the realm of metadata-driven architectures or table-driven architectures. 
• JM: if we can put business logic into code modules, aligned to business requirements in written form, we will see repetition even within functions that need to be tabularized. This will put us in a highly scalable architecture/part of a scalable solution. We can talk later about how much we will scale them.
• JM: this is critical if we ask Mr. Antley and others to start coding - a key differentiation. 
• JM: We also ask selves if functions should be built into base data? It's not uncommon to venture down a path where we ask if we can do this with ETL time.
• PA: we can't do this w/ETL time - until we know what our bounds are, we can't calculate the results.
• JM: We should assume we want to use functions at this point.
• PA: a ltd # of functions should be part of bedrock infrastructure from outset, but not incorporated created at query time, or otherwise SQL query will get so large that most people can't even read it. 
• PA: with With the power of functions, I can do one select statement and get results comparable to auto coverage report. Functions we're talking about right now will be created before extraction is run, + validated and tested. So we aren't creating functions at run time. They will be built into the database and utilized. 
• KS: Disagreed strongly with this, because we have to govern those functions and install them. Doesn't believe this is the right approach - we want to keep it as simple as possible and just run the script. Doesn't see the value of creating these elements ahead of time if we can create them as part of the script.
• PA: we have to do governance regardless, and not many functions made. e.g., 10 functions, tested, validated, and used repeatedly. The amount of testing a test bank to prove they are correct - govern these far more easily than, say, giving someone the ability to create the function at runtime. The amount of validate done w/extraction patterns goes up exponentially without the use functions.
• JM: the idea that we're codifying a certain body of knowledge in a schema is fairly standard. The logic has to exist somewhere - question is not does it need to exist, but where do we put it. Schema definition - putting it in the schema build - is a much more stable location. The question: does the pace of change match the pace of the place where we put it. Pace of extraction patterns - extremely high and dynamic and different every time.
• KS: not challenging logic but timing. Doesn't believe we need to go there for the MVP. More complicated parsing.
• PA: the amount of renaming (reformatting semicolons, etc.) is overwhelming. But we would set a KS: not challenging logic but timing. Doesn't believe we need to go there for the MVP. KS: More complicated parsing. PA: but we would set a delimiter. 
• PA: we are likely taking about 9 functions. First is DateDiv (takes 2 iso dates - givess us difference btwn dates/months). 1 function for each column in that table. 
• JM: if If we can develop a set of functions that map cleanly to business requirements - lucid enough that any businessperson can read it , - this represents a huge strength.
• KS: we've added a significant dependency on strong governance. Latest version at any time will be necessary for a user to run extraction patterns. Key consideration. (Potential drawback) We just put a huge burden on everyone having the latest version. 
• JM: but no worse than the fact that we'll need to govern it anyway. , and there will be versioning regardless. We will have the same challenges regardless. Without functions, all logic has to fit inside extraction patterns. Then we have to add more and more to script, we could end up with massive extraction patterns. Massive prework to get one basic result. Ignores our ability to take advantage of the inevitable repetition within our codes. Also creates issues with versioning. 
• JB:

...

• We will have governance-related obligations anyway. Wants to try to put a higher-level overview on our discussion -

...

• re:  impact of the adapter on our functionality and the operations it might need to perform.

Mr. Braswell presented a . Presented diagram w/various logical endpoints /API. Other types of interactions in addition to basic extraction. of an interface for API and the various types of resources that might be used. One of the central ideas behind this: this can and should be used whether these are call-ins or call-outs.  The diagram illustrates that there are other types of interactions in the adapter to the hosted node in addition to just processing the extract. 

• Details of how we perform the extract can be summarized by the two ellipses at the bottom and the middle <initiate data call processing> and <return data call results>.
• The diagram illustrates something fundamental: Since we are positing the notion of an interface to a hosted node, some of the functions that exist in the node itself - re: looking at the queue of requests or the UI that interacts with one of the Kubernetes containers to talk to the chain code - this particular function needs to be proxied out into some form of API call in this interface. JB is calling 
• function of knowing what's in the queue will need to be proxied out to some form of API.
• View Data Call request will ferret out specific request in the standing queue. 
• Approving data call request - part of the validation process.

...