Skip to content

BDMS-195: Create Polymorphic Notes Table#198

Closed
ksmuczynski wants to merge 11 commits into
stagingfrom
kas-notes-model
Closed

BDMS-195: Create Polymorphic Notes Table#198
ksmuczynski wants to merge 11 commits into
stagingfrom
kas-notes-model

Conversation

@ksmuczynski

@ksmuczynski ksmuczynski commented Oct 23, 2025

Copy link
Copy Markdown
Contributor

Why

This PR addresses the following problem / context:

  • Current implementation stores notes as text strings directly in models
  • This approach lacks structure, metadata, and searchability
  • Different entity types (Things, Locations) need a consistent way to store and retrieve notes
  • String-based notes don't support historical tracking or attribution

How

Implementation summary - the following was changed / added / removed:

  • Created a new polymorphic notes model with NotesMixin for reuse across entities
  • Updated Thing and Location models to use the new polymorphic relationship
  • Modified Pydantic schemas to represent notes as List[NoteResponse]
  • Added note_type attribute to categorize different kinds of notes
  • Implemented content field to store the actual note text

Notes

Any special considerations, workarounds, or follow-up work to note?

  • Tests are failing, but that is because test fixtures still need to be updated to use the new polymorphic notes structure.
  • Should discuss the advantages/disadvantages of having a separate endpoint for notes.

A polymorphic Notes table was needed to store all unstructured notes.

This commit creates the necessary polymorphic Notes table. Its purpose is to store all unstructured notes, categorized by a note_type. It should be used when a record might need more than one note,
when the notes need to be categorized, or when you need the ability to
search across all notes in the system. This is different from a dedicated
notes field on a specific table, which should be used to store a single,
intrinsic attribute of the record itself.
This commit introduces a new category, `notable_type`, to the
`lexicon.json` file. This category will serve as the central,
authoritative source for the controlled vocabulary used in the
polymorphic `noteable_type` columns
Removed the TODO comments about updating the lexicon file with 'notable_type' category and values. They have been added.
Added NotesMixin to db/base.py that provides polymorphic note capabilities to any model
that inherits from it. The mixin offers:

- A polymorphic one-to-many relationship to the Notes table using the notable_id/notable_type pattern
- Efficient loading with selectin strategy to prevent N+1 query issues
- A convenient add_note() factory method for creating new notes with proper polymorphic associations
- Clean separation between read (relationship) and write (method) operations

This mixin enables consistent note-taking across multiple entity types while maintaining
type safety and relationship integrity.
Added the NotesMixin to both Location and Thing models to enable polymorphic note
capabilities. This allows:

- Associating multiple categorized notes with locations and things
- Consistent note handling across entity types
- Type-safe access to notes through relationship loading
- Efficient loading of notes with selectin strategy

The NotesMixin provides both the notes relationship and add_note() method for these
models, enabling a clean API for both reading and creating notes.
…ation models

- Created new Pydantic schema for the Notes model
- Added polymorphic relationship `notes: List[NoteResponse] = []` to Thing and
  Location schemas for flexible data modeling.
- Resolved SQLAlchemy inspection error caused by circular import between
  Notes and Thing/Location models
- Updated relationship definitions in notes.py to use string-based
  SQL expressions instead of direct class references
- Maintained TYPE_CHECKING imports for proper type hinting while
  avoiding runtime circular dependencies
- Fixed the NotesMixin.add_note method by replacing the undefined
  pk_value reference with self.id
- This resolves the "Unresolved reference 'pk_value'" error in base.py
- Ensures proper note creation through the convenient factory method
- Complements previous circular import fixes in the polymorphic
  relationship structure

The change maintains the intended functionality of creating notes
associated with model instances while fixing a reference error
that was preventing proper execution.
The lexicon incorrectly categorized a type of note as `noteable_type`. It has been corrected to `note_type`

This resolves the error where tests for the location model were unable to locate the proper "note_type".
- Comment out string-type notes fields from CreateLocation and UpdateLocation schemas
- Ensure LocationResponse consistently uses notes as List[NoteResponse]
- Fix validation error where API was receiving string notes but expecting list type
- Complete transition to polymorphic notes relationship for location entities
- Update test data to create proper Note objects instead of using string values

This resolves the ResponseValidationError where the API expected notes to be a list
but received a string value ('these are some test notes').
@ksmuczynski ksmuczynski changed the title kas-notes-model BDMS-195: Create Polymorphic Notes Table Oct 23, 2025
@jirhiker

Copy link
Copy Markdown
Member

superseded by #241

@jirhiker jirhiker closed this Nov 10, 2025
@ksmuczynski ksmuczynski deleted the kas-notes-model branch December 10, 2025 18:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants