Files
MediaManager-core/src/main/proto/albumhasgenre.proto
T
Gustavo Henrique Santos Souza de Miranda a102b24ecd Implement AlbumHasGenre relationship management with CRUD operations
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>
2025-12-07 23:24:52 -03:00

46 lines
820 B
Protocol Buffer

syntax = "proto3";
option java_package = "com.mediamanager.protocol.messages";
option java_outer_classname = "AlbumHasGenreMessages";
package mediamanager.messages;
message AlbumHasGenre {
int32 id = 1;
int32 fk_album_id = 2;
int32 fk_genre_id = 3;
}
message CreateAlbumHasGenreRequest {
int32 fk_album_id = 1;
int32 fk_genre_id = 2;
}
message CreateAlbumHasGenreResponse {
AlbumHasGenre albumhasgenre = 1;
}
message GetAlbumHasGenresRequest {
}
message GetAlbumHasGenresResponse {
repeated AlbumHasGenre albumhasgenre = 1;
}
message GetAlbumHasGenreByIdRequest {
int32 id = 1;
}
message GetAlbumHasGenreByIdResponse {
AlbumHasGenre albumhasgenre = 1;
}
message DeleteAlbumHasGenreRequest {
int32 id = 1;
}
message DeleteAlbumHasGenreResponse {
bool success = 1;
string message = 2;
}