100 lines
4.8 KiB
Plaintext
100 lines
4.8 KiB
Plaintext
SEARCH SPECS
|
||
|
||
|
||
|
||
CASES
|
||
|
||
SEARCH: - to have ability to filter by client
|
||
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1503
|
||
|
||
SEARCH:UI:GENERAL: - Search in V8: should be integrated, not a separate form
|
||
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1672
|
||
|
||
SEARCH:NEW: - Search dictionary: Auto remove orphaned words
|
||
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1878
|
||
|
||
WORKORDER:PARTS:SEARCH:CR:DUPLICATE 3358: - Parts Search on Parts Grid
|
||
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3310
|
||
|
||
WORKORDER:PARTS:SEARCH:CR:DUPLICATE 3310: - Ability to ‘search’ for a part while in a WO or PM
|
||
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3358
|
||
|
||
UI:WORKORDER:CR: - Have a search box for clients instead of having to use the slider to find a client
|
||
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3376
|
||
|
||
SEARCH:UI:GENERAL: - Be able to search from anywhere in any screen
|
||
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3459
|
||
|
||
SEARCH:WORKORDER:PO:QUOTE:PM: - Workorder and other numbered items need to be searchable by their number
|
||
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3506
|
||
|
||
|
||
|
||
REQUIREMENTS
|
||
|
||
- USE-CASE: Central text search for any match. Can include tags. Can specify a type of object.
|
||
- USE-CASE: In-object text search for the typeandid that user is in, e.g. when in Client info form can search on that client.
|
||
- USE-CASE: Picklist / chooser Search for text of a specific type of object, e.g. find all Clients that contain "squirrel" to drive picklists everywhere
|
||
- USE-CASE: No snippet (excerpts) just name and type. I think for the initial release I'm *not* going to include snippets with result for several reasons:
|
||
- Performance: better to get an immediate result than to wait a while to get excerpts that
|
||
- Bandwidth: will trigger a lot of probably unneeded Bandwidth and chew up cycles on the db and server
|
||
- Can be added later based on feedback (i.e. a lot of bitching)
|
||
- For performance it would be something that runs *after* the search results are returned, either on demand (user clicks on excert button, or slowly fills in the list async)
|
||
|
||
- NAME: in search index include a bool indicating the word is actually part of the name or equivalent of the object, this will make name searches WAAAAYYY easier!!!
|
||
- in non named objects it's whatever the primary identifier is, i.e. workorder number for a workorder, partnumber for a part
|
||
- Maybe all objects should have a "name" column in db be it a workorder number or part number just for consistency
|
||
- TAGS: Any search, anywhere, can include tags (internally it will post filter on tags after initial text search or if no text then will just search tags)
|
||
|
||
- ROLES: Needs to internally be able to filter by CANREAD property of role user is in (e.g. if no rights to read client no clients returned)
|
||
- INDEX VISIBLE ID NUMBERS MUST be searchable so ensure they get put into text search with the regular text.
|
||
- OBJECT ID and/or OBJECT TYPE criteria support (AyaTypeId must be included in search index)
|
||
- PARENT / OPENABLE OBJECT: Objects that are searchable but not openable directly need to contain their parent type and id, this way we can follow a chain to the openeable object if necessary
|
||
- This is in the object, not in the searchkey as it would be inefficient
|
||
- Need parent AyaType as an ENUM ATTRIBUTE in the AyaType table for easy traversal
|
||
- CLEANUP: Generator able to cleanup index with no matching word (if possible), index with no matching typeandid
|
||
- CJK INDEX support: same as v7 but tied to Locale, not globally
|
||
- GROUP BY: group by objectype then objectid (then created date?)
|
||
- Coding: break this into separate discrete classes, the old v7 code is very monolithic and in-elegant
|
||
- SAMPLE DATA: Need a huge amount of sample data indexed to load test it
|
||
- INDEXES: play with it and see what works best
|
||
|
||
|
||
|
||
PROPOSED SCHEMA
|
||
asearchdictionary
|
||
- id (long)
|
||
- word (nvarchar 255) (indexed?)
|
||
|
||
asearchkey
|
||
- id (long)
|
||
- wordid (fk on asearchdictionary.id)
|
||
- objectid (long id of source object)
|
||
- objecttype (AyaType as int of source object)
|
||
- inname (bool indicates the search word was in the name of the object)
|
||
|
||
|
||
|
||
|
||
REFERENCE INFO
|
||
|
||
V7 Code:
|
||
- Word breaker: AyaBizUtils -> Break starting at line 1976
|
||
- Insert into db: DBUtil.cs -> ProcessKeywords starting at line 423
|
||
- Usage: Client.cs line 2104
|
||
- SearchResultList.cs (whole class, also there is an "ri" version for some reason I forget)
|
||
- V7 DB Schema:
|
||
|
||
CREATE TABLE [dbo].[ASEARCHDICTIONARY](
|
||
[AID] [uniqueidentifier] NOT NULL,
|
||
[AWORD] [nvarchar](255) NOT NULL
|
||
) ON [PRIMARY]
|
||
|
||
|
||
CREATE TABLE [dbo].[ASEARCHKEY](
|
||
[AWORDID] [uniqueidentifier] NOT NULL,
|
||
[ASOURCEOBJECTID] [uniqueidentifier] NOT NULL,
|
||
[ASOURCEOBJECTTYPE] [smallint] NOT NULL
|
||
) ON [PRIMARY]
|
||
|