This commit extends the Album entity with bidirectional relationship
management for the AlbumHasGenre join table, enabling many-to-many
associations between albums and genres with convenient helper methods.
Key enhancements:
Relationship Mapping:
- Added OneToMany relationship from Album to AlbumHasGenre
* Bidirectional mapping with cascade ALL and orphan removal
* Maintains collection of album-genre associations
* Initialized as ArrayList to prevent null pointer exceptions
* Follows the same pattern as albumArtists relationship
Helper Methods for Genre Management:
- addGenre(Genre genre):
* Creates AlbumHasGenre join table entry
* Sets bidirectional references to Album and Genre
* Adds association to albumGenres collection
* Simplifies adding genres to albums programmatically
- removeGenre(Genre genre):
* Removes association by comparing genre IDs
* Safely handles null checks
* Uses removeIf for clean collection manipulation
* Maintains referential integrity
- getGenres():
* Convenience method to extract Genre list from join table
* Uses Java streams for clean transformation
* Maps AlbumHasGenre → Genre
* Returns List<Genre> for easy consumption
Collection Management:
- Added getAlbumGenres() getter
* Returns full List<AlbumHasGenre> for direct access
* Useful for repository-level operations
- Added setAlbumGenres() setter
* Allows bulk replacement of genre associations
* Required by JPA for entity hydration
Benefits:
- Enables navigating from Album to associated Genres
- Simplifies genre association management in service layer
- Cascade operations ensure join table entries are managed automatically
- Orphan removal prevents orphaned join table entries
- Consistent API with existing Artist relationship methods
- Type-safe genre management through helper methods
Pattern Consistency:
This implementation mirrors the albumArtists relationship structure,
providing a consistent API for managing both artist and genre associations
on the Album entity. Both relationships use the same cascade and orphan
removal strategies for reliable data integrity.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit message is ready to use in IntelliJ for the Album.java changes!
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 completes the AlbumArt feature integration by registering
the service with the dependency injection system and updating repository
ignore rules.
Service Registration:
- Initialize AlbumArtRepository with EntityManagerFactory
- Create AlbumArtService instance with repository dependency
- Register AlbumArtService with ServiceLocator for handler injection
- Ensures all AlbumArt action handlers can resolve dependencies
The service follows the established initialization pattern used by other
entities (SamplingRate, BitDepth, BitRate, etc.) ensuring consistency
across the application architecture.
Repository Configuration:
- Add src/scripts/* to .gitignore for local script files
- Add local-repo/ to .gitignore for local Maven repository cache
- Prevents accidental commits of development artifacts and dependencies
These changes complete the AlbumArt feature, making it fully operational
and accessible through the action handler system.
🤖 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>
Enhance input validation and code quality in the SamplingRate service:
- Add null check for id parameter in updateSamplingRate() method to prevent
potential NullPointerException when calling repository.findById()
- Standardize indentation throughout the updateSamplingRate() method body,
improving code readability and consistency with project style guidelines
This complements the previous validation improvements by ensuring all
method parameters are properly validated before use, creating a more
defensive and robust API surface.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit addresses potential runtime exceptions and improves input validation:
- Replace Optional.of() with Optional.ofNullable() in SamplingRateRepository.findById()
to properly handle cases where no sampling rate is found, preventing NullPointerException
- Add null validation for id parameter in SamplingRateService.deleteSamplingRate()
to ensure proper error handling before repository operations
- Clean up code formatting in updateSamplingRate() validation block
These changes enhance the robustness of the sampling rate management feature
by preventing NPEs and providing clearer error messages for invalid inputs.
🤖 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.
- Add validation to ensure classes annotated with `@Action` implement `ActionHandler`, throwing `IllegalArgumentException` for mismatches.
- Fix minor formatting issue in `@Action` annotation for `GetGenreByIdHandler`.
- Replace manual handler registration with automatic scanning and registration of handlers annotated with `@Action`.
- Introduce `ServiceLocator` to enable dependency injection for dynamically instantiated handlers.
- Add `initializeServices` to centralize service initialization and registration.
- Enhance error handling and logging for handler instantiation and registration processes.
- Ensure `GenreMapper` sets ID only if it's non-null and valid (> 0) to prevent potential NPEs.
- Adjust logging format in `IPCManager` for consistent indentation.
- Wrap entity scanning in a try-catch block to handle potential exceptions.
- Log descriptive error messages and throw a runtime exception for failure cases.
- Warn if no `@Entity` classes are found during the scan.
Gustavo Henrique Santos Souza de Miranda