Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
Confluence
Teams
, (opens new window)
Requirement Yogi (Data Center)
Results will update as you type.
  • Getting Started - Tutorials
  • Administrator's guide
    • Configuration
    • Maintenance guide
    • Limitations
    • Migration to the Cloud
    • Requirement Yogi Cloud vs Data Center
    • Backup, import and export of Requirement Yogi data across Confluence and Jira instances
    • Database schema
    • Changing Applinks
    • Performance
    • Copying, Splitting and Moving pages
    • Choosing the indexing engine
      • Differences between Indexing Engine v1 and v2
      • Comparison tool for the indexation v1-v2
    • Notifications
    • Data Center SLA / Escalation process
    • History - Administrator's guide
  • Features
  • Requirement Yogi for Jira
  • RY Testing and Compliance
  • Integrations
  • APIs
  • Release notes
  • Archives (Legacy Features)
    Calendars
You‘re viewing this with anonymous access, so some content might be blocked.
/
Differences between Indexing Engine v1 and v2
Updated Apr 14

    Differences between Indexing Engine v1 and v2

    We require customers to move on to Indexing Engine v2. The requirements are indexed slightly differently. This page summarizes the XHTML / storage format differences between the two indexations.

     

    See Choosing the indexing engine for the intrinsic qualities of this engine.

    Note for Vertical Tables: The comparison tool will show the differences in dependencies, but it will not apply them (see “Vertical tables”).

    Tables and lists

    We don’t flatten lists and tables anymore.

    Bug scenario: None expected, this one will only make the users happier

    image-20250412-111519.png
    The storage data differences
    image-20250412-111534.png
    The visual differences

     

    Only the second column is used for the description

    We only use the first cell as the body of the requirement. All the other cells are stored as properties, and the text of properties is not repeated in the cells.

    image-20250412-101642.png
    The red part hasn’t been deleted, it is present in the properties (see table 2)
    image-20250412-101735.png
    The requirement’s table (table 2)
    image-20250412-110620.png
    When the requirement is in the second column (see table 3), the description is still extracted from the second column and is empty. But all columns are still extracted as properties, as before
    (the property First column = “PPP”).
    image-20250412-110732.png
    The requirement’s table (table 3)

     

     

    Bug scenario 1: If your requirement key is not in the first column, or if your second column doesn’t contain the requirement description, then your requirement will have no excerpt and all text will be in various properties.

    Bug scenario 2: When comparing requirements, you will notice there is less text in the description. This is because we don’t repeat the text of properties in the description. In our customer trials, surprisingly, most customers didn’t even notice and not a single question was raised. It is very visible during the comparison, but it seems more usable on a day-to-day basis.

    Workaround: If you really need all columns in your descriptions, then you will have to put an RY Property macro in each necessary column (tick: “✓ Title”).

    Rationale: Users didn’t understand why the same text was repeated in the description and properties. In most cases, the description of the requirement is indeed in the 2nd column, and in other situations, the RY Property macro can be used.

    Links

    We store the link’s relative URL:

    image-20250412-101942.png
    The differences in indexation
    image-20250412-102032.png
    The original table

     

    Bug scenario: You query the Requirement Yogi REST API programmatically to display those requirements in your own software.

    Workaround: You will have to render those links in your own software (That’s what we do in Jira).

    Rationale: It is more future-proof when you change the URL of Confluence, which happens for all our customers who have a merger-acquisition.

    Images

    We save a lot more attributes, and we save relative links (as explained in the previous paragraph about relative URLs)

    image-20250412-111142.png

    Bug scenario: None specific. It’s just a lot more data to save, and if image metadata changes often, it could look as modified between two baselines of the same requirement.

    Rationale: Customers complained that we reformatted documents in v1, and images were reduced to their minimum, so we store the image as rendered by Confluence.

    Vertical tables and parent/child dependencies

    In Indexing V1, we used to create automatic parent/child dependencies between vertical tables and the following requirements.

     

    Screenshot 2025-04-12 at 13.17.22.png

    Bug scenario: The comparison tool doesn’t show the differences, and upgrading those requirements doesn’t change their dependencies, but the next time they are indexed, dependencies will have changed.

    Workaround: You will have to update your tables like this:

    image-20250412-112016.png
    How tables must be written if you want dependencies between those requirements

    Rationale: Some customers would like to make other uses of the “parent” dependencies and this automatic dependency was disturbing to them. However, removing this system brought controversy, so we might reinstate it later.

    Scaffolding

     

    Configurations are varied, so please report any difference that is affecting your business.

     

    Some Scaffolding arrangements are not supported when they contain requirement definitions:

    • Recursive macros,

    • Repeat macros,

    • Excerpt/include macros with definitions: They will appear as duplicate definitions if they appear on several pages.

    There is extra HTML added to my requirements

    We save more HTML than before, and it sometimes leads to HTML such as div class=”content-wrapper”> to be inserted:

    image-20250413-084453.png

    Bug scenario: None. The rendered content is the same and it just occupies more space in a database.

    Rationale: We ackowledge those elements are visually polluting. However, there are added by Confluence and we have technical difficulties identifying them using a streaming parser (it would be easy using a DOM parser, but we try not to load the full XML of pages in RAM). Since they don’t cause issues, we don’t consider it a bug when they are present.

     

     

    {"serverDuration": 10, "requestCorrelationId": "7d63731bd2a94f3d9b7a02eaeb560bc2"}