Basic

https://www.geeksforgeeks.org/system-design/hexagonal-architecture-system-design/ - ====== - JDBC vs Hibernate vs JPA => https://levelup.gitconnected.com/jpa-vs-hibernate-vs-spring-data-jpa-63433dcaa6b9 - when you start spring application it goes to main method 1st where it reads the application.class name >@SpringBootApplication annotation -> instantiate spring container (application.properties is 1st file which is read when your container is being initiated) - > creates java objects ====== - @PostMapping("/product") public String createProduct(@RequestBody ProductDTO product){ return "product created"; } - as not @valid is added not request body validation will happen - ====== - "Found 0 JPA repository interfaces" - Hibernate is initialized but not finding any entities to map. The issue is that Spring Data JPA repositories aren't being scanned, so Hibernate doesn't know about the Product entity.

Add @EntityScan to explicitly tell Hibernate where to find entities: Added @EntityScan to tell Hibernate to look for entities in com.example.mastek.entity. This ensures the Product entity is discovered and the table is created on startup - ====== - ### why it should be import.sql and not any other name - Short answer: because import.sql is Hibernate’s built‑in default import file — Hibernate automatically looks for and runs import.sql on the classpath after it generates the schema. That guarantees your INSERTs run after tables are created.

Additional notes (brief):

Spring Boot also supports data.sql (Spring’s DataSource initializer). Behavior/order differs: data.sql is handled by Spring’s SQL initializer, while import.sql is executed by Hibernate after schema creation — so import.sql is the safer choice when Hibernate creates the schema. To use a different filename, configure it: Hibernate way: spring.jpa.properties.hibernate.hbm2ddl.import_files=your-file.sql Spring initializer way: spring.sql.init.data-locations=classpath:your-file.sql Place the file in resources so it’s on the classpath. - ====== - ## Purpose of Mappers: - Mappers convert one object to another (e.g., Entity ↔ DTO). They decouple your internal entity from external API contracts and provide a single place to handle conversions. - Flexibility to change Entity without affecting API - ====== - ## Constructor Injection vs Field Injection: - | Aspect | Constructor Injection | Field Injection (@Autowired) | | --- | --- | --- | | Immutability | ✅ Final fields possible | ❌ Must be non-final | | Testing | ✅ Easy to mock | ⚠️ Harder to mock (needs reflection) | | Null Safety | ✅ Guaranteed non-null | ❌ Can be null if not injected | | Circular Dependency | ✅ Catches at startup | ❌ Causes runtime errors | | Readability | ✅ Clear dependencies | ⚠️ Hidden dependencies | | Best Practice | ✅ Recommended | ⚠️ Discouraged | - ====== - @ControllerAdvice is a Spring stereotype that gets picked up by component scanning and registered as a bean at startup. Spring’s ExceptionHandlerExceptionResolver (a HandlerExceptionResolver) inspects controller handling errors. When a controller method throws an exception it: looks for an @ExceptionHandler method on the controller class itself, if none matches, it searches registered @ControllerAdvice beans for a matching @ExceptionHandler, the first matching handler (respecting @Order / HandlerExceptionResolver ordering and specificity) is invoked. So Spring “knows” to use your GlobalExceptionHandler because it is a bean annotated @ControllerAdvice and contains @ExceptionHandler methods; the resolver finds and calls those methods when exceptions occur during request handling. Notes: Ensure the class is in a package scanned by Spring Boot (same package or subpackage of your main application). You can restrict/target the advice via attributes (basePackages, annotations, assignableTypes) or change priority with @Order. - ======

Request to Response flow¶

Below is a concise end‑to‑end request flow (HTTP client → DB) for a typical Spring Boot app using Spring MVC + Spring Data JPA:

Client sends HTTP request (browser / curl / client lib) to your app URL.
HTTP container (Tomcat/embedded) receives the request and forwards to Spring's DispatcherServlet.
DispatcherServlet runs filters/interceptors, then uses HandlerMapping to find the matching @Controller/@RequestMapping handler.
If the handler has @RequestBody, an HttpMessageConverter (Jackson) deserializes JSON → Java DTO.
DispatcherServlet calls the controller method (Controller layer).
Controller delegates to the Service layer (usually via constructor-injected ProductService).
Service performs business logic, validation, and orchestration. It may:
call a Mapper to convert DTO ↔ Entity,
open/participate in a transaction (@Transactional),
call Repository methods.
Repository (Spring Data JPA) method is invoked. Spring Data creates a proxy that uses the JPA EntityManager.
EntityManager (Hibernate) translates entity operations into SQL:
flush pending changes,
generate SQL DDL/DML as needed.
Hibernate obtains a JDBC connection from the pool (HikariCP) and uses the JDBC driver (Postgres driver) to execute SQL on the DB.
DB executes SQL, returns results/rows to JDBC driver.
JDBC returns results to Hibernate; Hibernate maps ResultSet → entity objects.
Transaction manager commits/rolls back the DB transaction.
Service returns DTO/entity to Controller (may convert Entity → DTO via Mapper).
Controller returns a response object; HttpMessageConverter serializes it to JSON.
DispatcherServlet sends the HTTP response back to the client.
Any @ControllerAdvice / ExceptionHandler handles exceptions and converts into HTTP error responses.

Notes (brief):

Transactions: @Transactional typically begins at service layer; commit happens after repository operations succeed.
Lifecycle hooks: A spring import.sql or data initializer may run at startup before step 1.
Performance: Caching, lazy loading, N+1 issues occur at Hibernate/EntityManager layer and can affect DB queries.
======
======
======
======
======
======
======
======
======
======