<commit_before>
/*
 * An SQL database view
 * * @param {String} name: the name of the view
 * * @param {Object} name: the table object for the view
 *
 * Views and table have a complicated relationship:
 * 1. A view is a kind of table. So it's both a table object and a View object.
 * The table object points to the view object: table.view and vice versa, the
 * view object points to the table object view.table.
 * 2. The View object has a link of the tables that the view depends on in 
 * view.tables. Whenever one of these tables changes the view changes too.
 * 3. Each table that's not a view has a list of views that are affected by
 * it. This list could be empty. Thi is the reverse of 2 above.
 */

//An SQL database view
Devwik.SQL.View = function(name, table) {
	var self = this,
	row = Devwik.SQL.View.list[name];
	self.name = name;
	self.table = table;
	self.tables = []; //List of tables this view depends on
	self.dbKeys = []; //List of keys this view depends on
	self.updatable = row.IS_UPDATABLE;
	self.query = row.VIEW_DEFINITION;

	Fiber(function() {
		//Now let's find the list of tables affected
		var explain = 'explain ' + self.query;
		var infoRows = Devwik.SQL.execStatement(explain);
		_.each(infoRows, function(infoRow){ //For each table in the db<commit_msg>Document view handling<commit_after>
/*
 * An SQL database view
 * * @param {String} name: the name of the view
 * * @param {Object} name: the table object for the view
 *
 * We currently only support simple views in terms of reactivity: 
 * Each table in the view needs to have a unique key
 * There should be no aggregates in the view
 * We don't support updatable views
 *
 * Strategy
 * --------
 *
 * Views let each table in the view know that they're dependent on the table.
 * When the table is changed: insert, update, delete, it calls the view and lets
 * it know which row was affected. The view then handles the row(s). 
 * Deleting rows is more complicated since once the row is deleted in the db, 
 * we don't know which rows have been affected in the view. We therefor create a temp
 * table on startup where we keep all the keys to the view. When there's a delete,
 * we look in the temp table to see which rows were affected.
 *
 * Views and table have a complicated relationship:
 * 1. A view is a kind of table. So it's both a table object and a View object.
 * The table object points to the view object: table.view and vice versa, the
 * view object points to the table object view.table.
 * 2. The View object has a link of the tables that the view depends on in 
 * view.tables. Whenever one of these tables changes the view changes too.
 * 3. Each table that's not a view has a list of views that are affected by
 * it. This list could be empty. Thi is the reverse of 2 above.
 */

//An SQL database view
Devwik.SQL.View = function(name, table) {
	var self = this,
	row = Devwik.SQL.View.list[name];
	self.name = name;
	self.table = table;
	self.tables = []; //List of tables this view depends on
	self.dbKeys = []; //List of keys this view depends on
	self.updatable = row.IS_UPDATABLE;
	self.query = row.VIEW_DEFINITION;

	Fiber(function() {
		//Now let's find the list of tables affected
		var explain = 'explain ' + self.query;
		var infoRows = Devwik.SQL.execStatement(explain);
		_.each(infoRows, function(infoRow){ //For each table in the db
{'fraction_non_alphanumeric': 0.08482142857142858, 'fraction_numerical': 0.002380952380952381, 'mean_word_length': 3.364935064935065, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5472985', 'n_tokens_mistral': 1003, 'n_tokens_neox': 959, 'n_words': 502}