Add full Track implementation following the established pattern from Disc and Album entities.
Components added:
- Track entity model with relationships to Disc, Composer, BitDepth, BitRate, and SamplingRate
- TrackRepository for data access layer with full CRUD operations
- TrackService with business logic and validation
- TrackMapper for protobuf/entity conversion
- track.proto with all protobuf message definitions
- Five action handlers: Create, GetAll, GetById, Update, Delete
- TrackService registration in DelegateActionManager
The Track entity supports:
- Required fields: trackNumber, title, filepath, discId
- Optional fields: duration, composerId, bitDepthId, bitRateId, samplingRateId
- Full transaction management and error handling
- Proper validation and logging throughout all layers
This commit introduces the AlbumHasGenre join table entity management,
establishing the many-to-many relationship between Album and Genre
entities. This implementation follows the established repository pattern
used for other join table entities like AlbumHasArtist.
Key components implemented:
Model Layer:
- AlbumHasGenre entity representing the join table
- ManyToOne relationships to Album and Genre entities
- JPA annotations with proper foreign key constraints (nullable = false)
- Complete getters and setters
- Custom toString method for debugging
Repository Layer:
- AlbumHasGenreRepository with EntityManager-based operations
- Full transaction management with proper rollback handling
- Methods: save, findAll, findById, deleteById
- No update method (join tables typically only need create/delete)
Service Layer:
- AlbumHasGenreService with business logic and validation
- Constructor injection of AlbumHasGenreRepository, AlbumRepository, GenreRepository
- Relationship validation: ensures both Album and Genre exist before creating association
- Input validation for null/invalid IDs
- ID validation for all operations requiring entity lookup
- Comprehensive logging using Log4j2
Mapper Layer:
- AlbumHasGenreMapper for bidirectional entity/protobuf conversion
- Foreign key mapping for Album and Genre relationships
- Null safety checks and validation
- Proper handling of optional ID field
Action Handlers:
- CreateAlbumHasGenreHandler (albumhasgenre.create)
- GetAlbumHasGenreHandler (albumhasgenre.getAll)
- GetAlbumHasGenreByIdHandler (albumhasgenre.getById)
- DeleteAlbumHasGenreHandler (albumhasgenre.delete)
- HTTP status code handling: 200 (success), 400 (validation),
404 (not found), 500 (server error)
- No update handler as join tables typically only require create/delete operations
Protocol Buffers:
- Complete proto definition with AlbumHasGenreMessages
- Messages support fk_album_id and fk_genre_id foreign keys
- CRUD message definitions (Create, Get, GetById, Delete)
- No Update messages as per join table requirements
Service Registration:
- AlbumHasGenreRepository initialized with EntityManagerFactory
- AlbumHasGenreService registered with ServiceLocator with required dependencies
- Ensures all AlbumHasGenre action handlers can resolve dependencies
- Proper dependency injection of AlbumRepository and GenreRepository
The implementation follows best practices with proper error handling,
logging, validation, relationship integrity checks, and consistency with
existing codebase patterns. This enables proper many-to-many relationship
management between albums and genres, allowing albums to be associated
with multiple genres and vice versa.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit introduces significant improvements to the Album entity and its
update functionality, adding bidirectional relationship management with
AlbumHasArtist and implementing proper partial update semantics using
protobuf wrapper types.
Key enhancements:
Model Layer Improvements:
- Added OneToMany relationship from Album to AlbumHasArtist
* Bidirectional mapping with cascade ALL and orphan removal
* Maintains collection of album-artist associations
- Implemented helper methods for artist management:
* addArtist(): creates and adds AlbumHasArtist association
* removeArtist(): removes association by artist ID
* getArtists(): convenience method to extract Artist list from associations
- Added getters/setters for albumArtists collection
- Improved entity relationship management
Service Layer Enhancements:
- Refactored updateAlbum() to support partial updates
- Added boolean flags to control field updates:
* updateYear: controls whether year field should be modified
* updateNumberOfDiscs: controls disc count updates
* updateAlbumType: controls AlbumType relationship updates
* updateAlbumArt: controls AlbumArt relationship updates
- Only updates fields when explicitly provided by client
- Maintains existing values for non-provided fields
- Allows explicit null/removal of optional relationships
- Improved update logic clarity and maintainability
Handler Layer Improvements (UpdateAlbumHandler):
- Integrated protobuf wrapper type handling
- Uses hasYear(), hasNumberOfDiscs(), etc. to detect field presence
- Extracts values from Int32Value wrappers
- Passes presence flags to service layer
- Properly distinguishes between "not provided" and "null/0"
- Improved code formatting and readability
Protocol Buffer Enhancements:
- Added import for google.protobuf.wrappers
- Changed UpdateAlbumRequest optional fields to wrapper types:
* year: int32 → google.protobuf.Int32Value
* number_of_discs: int32 → google.protobuf.Int32Value
* fk_albumtype_id: int32 → google.protobuf.Int32Value
* fk_albumart_id: int32 → google.protobuf.Int32Value
- Enables proper optional field semantics
- Allows clients to omit fields from update requests
- Supports explicit null to remove relationships
Benefits of these changes:
- Proper partial update support: clients can update only specific fields
- Prevents unintended field overwrites with default values
- Bidirectional navigation from Album to Artists
- Cascade operations for album-artist associations
- Cleaner API semantics with explicit field presence detection
- Better alignment with REST PATCH semantics
- Maintains backward compatibility for required fields
Example usage:
- Update only name: provide name, omit other fields
- Remove AlbumType: provide fk_albumtype_id with value 0 or null
- Keep existing year: omit year field from request
- Update multiple fields: provide only the fields to change
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit introduces the AlbumHasArtist join table entity management,
establishing the many-to-many relationship between Album and Artist
entities. This implementation follows the established repository pattern
used for other entities.
Key components implemented:
Model Layer:
- AlbumHasArtist entity representing the join table
- ManyToOne relationships to Album and Artist entities
- JPA annotations with proper foreign key constraints
- Complete getters and setters
- Custom toString method for debugging
Repository Layer:
- AlbumHasArtistRepository with EntityManager-based operations
- Full transaction management with proper rollback handling
- Methods: save, findAll, findById, deleteById
- No update method (join tables typically only need create/delete)
Service Layer:
- AlbumHasArtistService with business logic and validation
- Constructor injection of AlbumHasArtistRepository, AlbumRepository, ArtistRepository
- Relationship validation: ensures both Album and Artist exist before creating association
- Input validation for null/invalid IDs
- ID validation for all operations requiring entity lookup
- Comprehensive logging using Log4j2
Mapper Layer:
- AlbumHasArtistMapper for bidirectional entity/protobuf conversion
- Foreign key mapping for Album and Artist relationships
- Null safety checks and validation
- Proper handling of optional ID field
Action Handlers:
- CreateAlbumHasArtistHandler (albumhasartist.create)
- GetAlbumHasArtistHandler (albumhasartist.getAll)
- GetAlbumHasArtistByIdHandler (albumhasartist.getById)
- DeleteAlbumHasArtistHandler (albumhasartist.delete)
- HTTP status code handling: 200 (success), 400 (validation),
404 (not found), 500 (server error)
- No update handler as join tables typically only require create/delete operations
Protocol Buffers:
- Complete proto definition with AlbumHasArtistMessages
- Messages support album_id and artist_id foreign keys
- CRUD message definitions (Create, Get, GetById, Delete)
- No Update messages as per join table requirements
Service Registration:
- AlbumHasArtistRepository initialized with EntityManagerFactory
- AlbumHasArtistService registered with ServiceLocator with required dependencies
- Ensures all AlbumHasArtist action handlers can resolve dependencies
- Proper dependency injection of AlbumRepository and ArtistRepository
The implementation follows best practices with proper error handling,
logging, validation, relationship integrity checks, and consistency with
existing codebase patterns. This enables proper many-to-many relationship
management between albums and artists.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit introduces comprehensive Album entity management following
the established repository pattern used for other entities like AlbumType
and SamplingRate. The Album entity includes relationships with AlbumType
and AlbumArt entities.
Key components implemented:
Model Layer:
- Album entity with complete field set:
* Basic fields: id, name, year, numberOfDiscs, code, isCompilation
* Foreign key relationships: AlbumType and AlbumArt (ManyToOne)
* Audit timestamps: createdAt, updatedAt with JPA lifecycle hooks
- JPA annotations with @PrePersist and @PreUpdate for automatic timestamps
- Complete getters and setters
Repository Layer:
- AlbumRepository with EntityManager-based operations
- Full transaction management with proper rollback handling
- Methods: save, findAll, findById, update, deleteById
Service Layer:
- AlbumService with business logic and validation
- Constructor injection of AlbumRepository, AlbumTypeRepository, AlbumArtRepository
- Relationship handling: validates and sets AlbumType and AlbumArt entities
- Input validation for null/empty name field
- ID validation for all operations requiring entity lookup
- Comprehensive logging using Log4j2
Mapper Layer:
- AlbumMapper for bidirectional entity/protobuf conversion
- Timestamp conversion between LocalDateTime and epoch milliseconds
- Foreign key mapping for AlbumType and AlbumArt relationships
- Null safety checks and validation
- Proper handling of optional fields
Action Handlers:
- CreateAlbumHandler (album.create)
- GetAlbumHandler (album.getAll)
- GetAlbumByIdHandler (album.getById)
- UpdateAlbumHandler (album.update)
- DeleteAlbumHandler (album.delete)
- HTTP status code handling: 200 (success), 400 (validation),
404 (not found), 500 (server error)
- Handles optional fields with proper default value checks
Protocol Buffers:
- Fixed proto definition with correct Album fields
- CreateAlbumRequest and UpdateAlbumRequest with all entity fields
- All CRUD message definitions (Create, Get, GetById, Update, Delete)
- Support for foreign keys and timestamps
Service Registration:
- AlbumRepository initialized with EntityManagerFactory
- AlbumService registered with ServiceLocator with required dependencies
- Ensures all Album action handlers can resolve dependencies
The implementation follows best practices with proper error handling,
logging, validation, relationship management, and consistency with
existing codebase patterns.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit introduces comprehensive AlbumType entity management following
the established repository pattern used for other entities like SamplingRate
and AlbumArt.
Key components implemented:
Model Layer:
- AlbumType entity with id and value fields
- JPA annotations for database persistence
- Complete getters and setters
Repository Layer:
- AlbumTypeRepository with EntityManager-based operations
- Full transaction management with proper rollback handling
- Methods: save, findAll, findById, update, deleteById
Service Layer:
- AlbumTypeService with business logic and validation
- Input validation for null/empty value fields
- ID validation for all operations requiring entity lookup
- Comprehensive logging using Log4j2
Mapper Layer:
- AlbumTypeMapper for bidirectional entity/protobuf conversion
- Null safety checks and validation
- Proper handling of optional ID field
Action Handlers:
- CreateAlbumTypeHandler (albumtype.create)
- GetAlbumTypeHandler (albumtype.getAll)
- GetAlbumTypeByIdHandler (albumtype.getById)
- UpdateAlbumTypeHandler (albumtype.update)
- DeleteAlbumTypeHandler (albumtype.delete)
- HTTP status code handling: 200 (success), 400 (validation),
404 (not found), 500 (server error)
Protocol Buffers:
- Complete proto definition with AlbumTypeMessages
- All CRUD message definitions (Create, Get, GetById, Update, Delete)
Service Registration:
- AlbumTypeRepository initialized with EntityManagerFactory
- AlbumTypeService registered with ServiceLocator for dependency injection
- Ensures all AlbumType action handlers can resolve dependencies
The implementation follows best practices with proper error handling,
logging, validation, and consistency with existing codebase patterns.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit introduces comprehensive AlbumArt entity management following
the established repository pattern used for other entities like SamplingRate.
Key components implemented:
Model Layer:
- AlbumArt entity with id and filepath fields
- JPA annotations for database persistence
Repository Layer:
- AlbumArtRepository with EntityManager-based operations
- Full transaction management with proper rollback handling
- Methods: save, findAll, findById, update, deleteById
Service Layer:
- AlbumArtService with business logic and validation
- Input validation for null/empty filepath values
- ID validation for all operations requiring entity lookup
- Comprehensive logging using Log4j2
Mapper Layer:
- AlbumArtMapper for bidirectional entity/protobuf conversion
- Null safety checks and validation
- Proper handling of optional ID field
Action Handlers:
- CreateAlbumArtHandler (albumart.create)
- GetAlbumArtHandler (albumart.getAll)
- GetAlbumArtByIdHandler (albumart.getById)
- UpdateAlbumArtHandler (albumart.update)
- DeleteAlbumArtHandler (albumart.delete)
- HTTP status code handling: 200 (success), 400 (validation),
404 (not found), 500 (server error)
Protocol Buffers:
- Fixed java_outer_classname from "BitDepthMessages" to "AlbumArtMessages"
- All CRUD message definitions (Create, Get, GetById, Update, Delete)
The implementation follows best practices with proper error handling,
logging, validation, and consistency with existing codebase patterns.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Standardize the naming convention by changing `GetSamplingRateByIDRequest`
to `GetSamplingRateByIdRequest`, using "Id" instead of "ID" for consistency
with other proto message names across the codebase. Updated the corresponding
handler to reference the corrected message name.
This aligns with the established naming pattern and improves code consistency
following the same convention applied in other proto definitions.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit introduces comprehensive sampling rate management functionality
to the MediaManager system, following the established patterns from BitDepth
and BitRate implementations.
Core Components Added:
- SamplingRate entity model with JPA annotations for database persistence
- SamplingRateRepository with full CRUD operations (save, findAll, findById, update, deleteById)
- SamplingRateService business logic layer with validation and error handling
- SamplingRateMapper for bidirectional entity-protobuf conversions
Protocol Buffers:
- Defined samplingrate.proto with complete message specifications
- SamplingRate message structure (id, value)
- Request/Response pairs for all CRUD operations (Create, GetAll, GetById, Update, Delete)
- Fixed typo in UpdateSamplingRateRequest (valeu -> value)
Action Handlers:
- CreateSamplingRateHandler: Validates and creates new sampling rate entries
- GetSamplingRateHandler: Retrieves all sampling rates from the database
- GetSamplingRateByIdHandler: Fetches individual sampling rates with 404 handling
- UpdateSamplingRateHandler: Updates existing sampling rates with validation
- DeleteSamplingRateHandler: Removes sampling rates with success confirmation
Integration:
- Registered SamplingRateService in DelegateActionManager
- All handlers follow the @Action annotation pattern for automatic discovery
- Consistent error handling with appropriate HTTP status codes (400, 404, 500)
This implementation provides a complete foundation for managing audio sampling
rates within the media management system, enabling clients to perform all
standard CRUD operations through the established protocol buffer interface.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Change field name from 'Artist' to 'artist' to follow protobuf naming conventions, which require lowercase field names with underscores for word separation.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Add complete CRUD functionality for bit-rate management following the same pattern as bit-depth:
- Create BitRate entity model with JPA annotations
- Implement BitRateRepository with full CRUD operations
- Add BitRateService with validation and business logic
- Create BitRateMapper for protobuf/entity conversion
- Implement action handlers: Create, GetAll, GetById, Update, Delete
- Define bitrate.proto protobuf message definitions
- Register BitRateService in DelegateActionManager
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Add `BitDepth` entity with JPA annotations and database mapping.
- Create repository, service, and delegate handlers for BitDepth CRUD operations: `bitdepth.create`, `bitdepth.getAll`, `bitdepth.getById`, `bitdepth.update`, `bitdepth.delete`.
- Introduce Protobuf definitions for BitDepth messages.
- Register BitDepth service and handlers in `DelegateActionManager`.
- Create `BitDepthMapper` to map between Protobuf and entity models.
- Enhance error handling and logging for BitDepth operations.
- Add `Composer` entity with JPA annotations and database mapping.
- Create repository, service, and delegate handlers for Composer CRUD operations: `create_composer`, `get_composers`, `get_composer_by_id`, `update_composer`, `delete_composer`.
- Introduce Protobuf definitions for Composer messages.
- Register Composer service and handlers in `DelegateActionManager`.
- Add `ComposerMapper` to map between Protobuf and entity models.
- Enhance error handling and logging for Composer operations.
- Add `Artist` entity with JPA annotations and database mapping.
- Create repository, service, and delegate handlers for Artist CRUD operations.
- Register handlers (`artist.create`, `artist.getAll`, `artist.getById`, `artist.update`, `artist.delete`) in `DelegateActionManager`.
- Introduce Protobuf definitions for Artist messages.
- Update `initializeServices` in `DelegateActionManager` for Artist service support.
- Add null-safe ID handling in `ArtistMapper` to prevent potential NPEs.
- Extend `test.proto` with `CloseCommand` and `CloseResponse` messages.
- Introduce `CloseHandler` to process "close" actions and respond with connection termination notice.
- Update `DelegateActionManager` to register `CloseHandler`.
- Refactor `IPCManager` to handle "close" response headers and terminate client connections gracefully.
- Extend `test.proto` schema with heartbeat and echo message definitions.
- Register `HeartbeatHandler` in `DelegateActionManager`.
- Refactor Log4j2 configuration to standardize log levels.
- Optimize client wait time in `IPCManager` for reduced latency.
- Replaced `SimpleProtocol` with `TransportProtocol` in `IPCManager`.
- Added `DelegateActionManager` to route requests to handlers, starting with `EchoHandler`.
- Updated `MediaManagerApplication` to initialize and manage `DelegateActionManager`.
- Extended Protocol Buffers schema with `Request` and `Response` definitions.
- Enhanced logging for request processing and redesigned response flow.
- Created `messages.proto` to define `TextMessage` schema.
- Integrated Protocol Buffers Java library into Maven dependencies.
- Configured Maven plugins for Protocol Buffers compilation and generated source management.
- Implemented message serialization and deserialization in `IPCManager`.
- Enhanced client handling to process and respond with Protocol Buffers messages.
