| source text | options | matching query | non-matching query |
|---|---|---|---|
| C. S. Lewis | tbd | C S Lewis | CS Lewis |
| 75 | tbd | 7 | 0.7 |
| 75% | tbd | 75 | % |
| nav_power_on | tbd | power_on | power on |
| Books | tbd | booK | bookes |
| source text | tbd | matching query | non-matching query |
Test Cases
;
:* Case sensitive
:* Match word order (no effect with 1 search term)
:* Include leading punctuation
:* Include trailing punctuation
:* Whole content match
:* Whole word match
osee_search_url(BIGINT url_id, Varchar(128) title, Varchar(2048) url, valid_test_time) PRIMARY KEY (url_id) ORGANIZATION INDEX
:* title - search terms will be extracted from the title using the query parser steps and stored with rank name
:* url uniqueness is enforced via atomic insert command
:: INSERT INTO osee_search_url m1 (match_id, name, url, valid_test_time) SELECT ?,?,?,? FROM dual WHERE NOT EXISTS (SELECT 1 From osee_search_url m2 WHERE m2.url = ?)
:* maintenance operation identifies dead links. valid_test_time is updated with current date and time when the link is tested as valid
osee_search_term(Varchar(128) text, SMALLINT match_type_id, BIGINT app_id, SMALLINT rank_type_id, BIGINT term_group_id, SMALLINT term_group_size, BIGINT match_id) PRIMARY KEY (text, match_type, term_group_id, match_id) ORGANIZATION INDEX COMPRESS 2
:* text is normalized search term (see query parser steps)
:* match type
:: artifact, attribute, relation (for rationale), url type
:* app_id
:* match_id can be a osee_search_url.url_id or an attribute or relation gamma_id (or possibly extended to any other id)
:* the rank allows early exclusion of unwanted term types such as content with the sql criteria that only includes rank > 20
:* Results are returned in ascending rank order of the sum of all ranks for a match_id
:* rank_type_id:
1 \[220\] unique id - (employee id, charge number, USPS Tracking number, etc.) 2 \[200\] keyword - terms that when searched together should represent a top result 3 \[ 40\] tag (meta) - terms applied by human intelligence to classify and categorize 4 \[ 20\] content - terms extracted from the content body using the query parser steps 5 \[ 10\] team - relevant to a given team
type name
:* term_group_id - 1 when the term_group_size is 1; otherwise randomly generated id used to group search terms to apply a rank only when all terms in the group match
osee_search_query(BIGINT query_hash, Varchar(500) query_text, SMALLINT status, BIGINT top_match)
:* CREATE INDEX OSEE_SEARCH_QUERY_TEXT_IDX ON OSEE_SEARCH_QUERY (QUERY_TEXT);
:* query_hash is computed using the Query Parser Steps
:* query_text exactly as entered
:* status
::* no results
::* unverified results
::* verified results
:* top_match is the top match returned the last time this query was run. Useful for sharing links/ searches. consider supporting more than 1 top matches
:* search prediction based on query_text with past queries of user sorted first
osee_search_share(BIGINT to_user, BIGINT from_user, BIGINT query_hash, timestamp time) PRIMARY KEY (to_user, from_user, query_hash) ORGANIZATION INDEX COMPRESS 2
osee_search_history(BIGINT item_id, BIGINT user_id, timestamp) PRIMARY KEY (item_id, user_id, timestamp) ORGANIZATION INDEX COMPRESS 2
:* Allow request to specify max number of links or all (default is 25). Top ranked n links are returned as json {id, name, url, search terms, rank}
:* in order to set access control on a link you have to have the access to the group you are setting it to, you can add anyone else
When entering a new URL the name is initially populated from the web page title
Search results will include a why link that provides the rank information and allows users to improve this information
osee_tuple3(tx_key_type, branch_id, tx_id, attr_id, gamma_id)
osee_tuple2(relation_type, a_art_id, b_art_id, gamma_id)
osee_tuple2(BIGINT my_table_type, BIGINT row_id, String row_data, gamma_id)
:* the row_id allows the rows to be returned in order, also allows showing history of a given row
:* the row_data stores the json representing the row data
osee_tuple2 (tuple_type, element1, element2, gamma_id) PRIMARY KEY (tuple_type, element1, element2) ORGANIZATION INDEX COMPRESS 2; osee_tuple3 (tuple_type, element1, element2, element3, gamma_id) PRIMARY KEY (tuple_type, element1, element2, element3) ORGANIZATION INDEX COMPRESS 2; osee_tuple4 (tuple_type, element1, element2, element3, element4, gamma_id) PRIMARY KEY (tuple_type, element1, element2, element3, element4) ORGANIZATION INDEX COMPRESS 3; unique index: gamma_id
osee_txs (branch_id, transaction_id, gamma_id, tx_current, mod_type, app_id)
Default value for app_id in osee_txs is 1 which means in all views (base). View artifacts are on the product line branches.
osee_tuple2 (CoreTupleTypes.ViewApplicability, ArtifactId view, String applicabilityText, gammaId)
The view applicability tuples and view artifacts are on the product line branches thus maintaining full transactional history. The applicability text is the feature applicability text or the name of the of the view for non product line engineering use of views. Each view will be mapped to applicability id 1 (Base) so that base will be included for all configs by simply joining on the view_id. The featureApplicabilityId is the randomly generated key to applicabilityText in osee_key_value.
osee_tuple3 (CoreTupleTypes.BranchView, BranchId branch, ArtifactId view, String name, BIGINT gammaId)
Views are stored as artifacts of type "Branch View" on the branch their are views of. Named branch-views are stored as tuples on the common branch. These are used to populate the list of branches faster than searching and loading every "Branch View" on every branch. The branch view is accessed via BranchId.getView()
osee_tuple4 (app_feature_tuple_type, app_id, feature_id, value_attr_id, and_or_flag, gamma_id)
The Feature artifact has an attribute for each possible value. It also has a name, description, abbreviation, and type (single or multi-valued).
osee_tuple3 (compound_app_tuple_type, app_id, app_id, and_or_flag, gamma_id)
-- return all items (referenced by gamma_id) currently in a view of a branch select * from osee_txs txs, osee_tuple2 app where branch_id = ? and tx_current = 1 and txs.app_id = app.e2 and e1 = ?; -- applicability clause in SQL is only applied when using a branch view -- select applicability for a given view (e1) select e2, value from osee_txs txs, osee_tuple2 app, osee_key_value where tuple_type = 2 and e1 = ? and app.gamma_id = txs.gamma_id and branch_id = ? and tx_current = 1 and e2 = key;
:* Log entry in Java: BIGINT entryId, BIGINT parentId, BIGINT typeId, BIGINT startTime, BIGINT duration, BIGINT agentId, BIGINT status, String msgArgs
:* entry_id - random long returned for log method call
:* parent_id - id of entry used for grouping this and related entries. For root entries, it is the negative of session id of the client or the server id. Ranges are used to group by client/server kind (IDE client, app server, rest client).
:* type_id - foreign key to type_id in osee_log_type table
:* start_time - long with ms since epoch
:* duration - starts at -1 and is never updated if duration does not apply, otherwise updates when the associated job ends with duration in ms
:* account_id - long account id (the account_id returned from account management services
:* status:
0 initial value 1-99 percent complete 100 completed normally 101 completed abnormally
:* msg_args newline separated list of strings used with String.format(msg_format, msg_args);
Long createThreadEntry(long userId, Long typeId); Long createThreadEntry(long userId, Long typeId, long parentId); Long createEntry(Long typeId, Object... messageArgs); Long createEntry(Long typeId, Long parentId, Object... messageArgs); void updateEntry(Long entryId, Long status); Long createExceptionEntry(Throwable throwable);
Checked exceptions I love you, but you have to go Why should you use Unchecked exceptions over Checked exceptions Clean Code by Example: Checked versus unchecked exceptions
We have adopted JSON Forms to supply this capability, but have written our own Angular JS controls to support the capability to have each control have its own REST calls. All of the controls in the box below additionally provide links for getting and setting data. This allows the page to update and check data one control at a time.
Text box control: Similar to the JSON Forms text control. Checkbox control: Similar to the JSON Forms checkbox. Multi-line text box control: Provides a resizeable multi line text box. Dropdown control: Similar to the JSON Forms dropdown control. Multi-select Dropdown control: Wraps popular dotansimha Angular JS Multiselect Dropdown. Program-version control: a special case of the multi select dropdown to support selection of OSEE ATS program and version. Table control: wraps Angular UiGrid control to allow for table data.
Branches are private to their own OSEE repository, but distributed IDs are used to avoid future ID collisions between OSEE repositories. Implementation Note: IDs are randomly generated, except transactions which are numbered sequentially on a per branch basis (avoids transaction collisions since transaction ids can't be random due to max transaction calculations)
A branch may be cloned from the source OSEE repository into a destination repository as a read-only branch that will automatically update when network connectivity exists between the two repositories. Note: any repository may request to clone a branch from another repository. If the request is granted the source repository marks its branch as source and then allows the clone.
The branch updates for a cloned branch will also be able to be performed via an export of the source updates to the file system followed by an import in the OSEE that has the cloned branch.
A branch may be bidirectionally shared between OSEE repositories. The OSEE repository of the source branch tracks the branch lock. Other OSEE repositories start with a clone of the shared branch. In order for any OSEE to commit a transaction to the shared branch, it will first acquire the branch lock from the source repository. All transactions from the source are copied to the other repositories.
osee_search_hash ( match_type app_id term_hash art_id gamma_id)
osee_attribute (art_id, type_id, item_id, order, gamma_id, value)
Binary data is rare and often large and is never searched directly (instead it is tokenized and indexed) so Store it in an iot with the gamma_id as key
-- return all attributes for a given artifact currently in a view of a branch select * from osee_txs txs, osee_tuple2 app where branch_id = ? and tx_current = 1 and txs.app_id = app.e2 and e1 = ?; -- applicability clause in SQL is only applied when using a branch view -- select applicability for a given view (e1) select e2, value from osee_txs txs, osee_tuple2 app, osee_key_value where tuple_type = 2 and e1 = ? and app.gamma_id = txs.gamma_id and branch_id = ? and tx_current = 1 and e2 = key;