how to edit pushed commit message

Open the Intellij,  Go to version control tab, then go to log.
Selecting a commit, press F2 and then edit the commit message.

Open git bash
Now it should see the bias between local and remote;
git pull; and it will merge the remote and local

It will popup a vi editor to ask for editing the merge message;
Edit the text;

Press ESC, and press shift + zz; then quit to the git bash command line.

now

now, the local will be ahead of the remote, do
git push.

Disable SpringBoot Security

My solution is to define a flag in property file, and injected it during the runtime;


Using the @Value, and maybe combined with @ProperySource , I am using spring boot 2.0 and found that the application property file already read in the Spring context.

spring-value-annotation



There are several options, the following may be an option for the boot 1.5

security.basic.enabled=false
management.security.enabled=false

Injecting Property Value in Spring boot 2

the property value active should be injected from the property file.

@Value("${spring.profiles.active}")
private String activeProfile;


spring-value-annotation

Kotlin

In general, Kotlin is an upgraded Java

Kotlin has no primitive types; only the Objects(wrapper classes in java)

Kotlin has no semi-coma, and keyword new,
Kotlin has no checked exceptions; so there is no forced catch.

Kotlin may have a single primary constructor defined at the class header.

By default, all classes defined are immutable, equal to final classes in Java; so it needs an open modifier to make it extendable.

Kotlin has no checked exception, all exceptions are derived from the throw-able.


Kotlin function can be independent of a class; by default, it is a static method, it must be a static method, for doesn't belong to any class. A function can be modified access modifiers. A private function means it can be only accessed within its file scope.






return Unit

WebClient Spring 5 vs RestTemplate

Web-client in Spring 5 supports non-blocking asynchronous communications, however, RestTemplate is implemented in a blocking way.

spring-5-webclient

Flyway - Database Migration Tool

flyway maven 

flyway spring boot example

Direction in Entity Relationships

The direction of a relationship can be either bidirectional or unidirectional. A bidirectional relationship has both an owning side and an inverse side. A unidirectional relationship has only an owning side. The owning side of a relationship determines how the Persistence runtime makes updates to the relationship in the database.

Bidirectional Relationships

In a bidirectional relationship, each entity has a relationship field or property that refers to the other entity. Through the relationship field or property, an entity class’s code can access its related object. If an entity has a related field, the entity is said to “know” about its related object. For example, if Order knows what LineItem instances it has and if LineItem knows what Order it belongs to, they have a bidirectional relationship.

Bidirectional relationships must follow these rules.

• The inverse side of a bidirectional relationship must refer to its owning side by using the mappedBy element of the @OneToOne, @OneToMany, or @ManyToMany annotation. The mappedBy element designates the property or field in the entity that is the owner of the relationship.
• The many side of many-to-one bidirectional relationships must not define the mappedBy element. The many side is always the owning side of the relationship.
• For one-to-one bidirectional relationships, the owning side corresponds to the side that contains the corresponding foreign key.
• For many-to-many bidirectional relationships, either side may be the owning side.

Unidirectional Relationships

In a unidirectional relationship, only one entity has a relationship field or property that refers to the other. For example, LineItem would have a relationship field that identifies Product, but Product would not have a relationship field or property for LineItem. In other words, LineItem knows about Product, but Product doesn’t know which LineItem instances refer to it.

Queries and Relationship Direction

Java Persistence query language and Criteria API queries often navigate across relationships. The direction of a relationship determines whether a query can navigate from one entity to another. For example, a query can navigate from LineItem to Product but cannot navigate in the opposite direction. For Order and LineItem, a query could navigate in both directions because these two entities have a bidirectional relationship.

Cascade Operations and Relationships

Entities that use relationships often have dependencies on the existence of the other entity in the relationship. For example, a line item is part of an order; if the order is deleted, the line item also should be deleted. This is called a cascade delete relationship.

The javax.persistence.CascadeType enumerated type defines the cascade operations that are applied in the cascade element of the relationship annotations. Table 20–1 lists the cascade operations for entities.

Table 20–1 Cascade Operations for Entities

Cascade Operation	Description
ALL	All cascade operations will be applied to the parent entity’s related entity. All is equivalent to specifying cascade={DETACH, MERGE, PERSIST, REFRESH, REMOVE}
DETACH	If the parent entity is detached from the persistence context, the related entity will also be detached.
MERGE	If the parent entity is merged into the persistence context, the related entity will also be merged.
PERSIST	If the parent entity is persisted into the persistence context, the related entity will also be persisted.
REFRESH	If the parent entity is refreshed in the current persistence context, the related entity will also be refreshed.
REMOVE	If the parent entity is removed from the current persistence context, the related entity will also be removed.

Cascade delete relationships are specified using the cascade=REMOVE element specification for @OneToOne and @OneToManyrelationships. For example:

@OneToMany(cascade=REMOVE, mappedBy="customer")
public Set getOrders() { return orders; }

Orphan Removal in Relationships

When a target entity in one-to-one or one-to-many relationship is removed from the relationship, it is often desirable to cascade the remove operation to the target entity. Such target entities are considered “orphans,” and the orphanRemoval attribute can be used to specify that orphaned entities should be removed. For example, if an order has many line items and one of them is removed from the order, the removed line item is considered an orphan. If orphanRemoval is set to true, the line item entity will be deleted when the line item is removed from the order.

The orphanRemoval attribute in @OneToMany and @oneToOne takes a Boolean value and is by default false.

The following example will cascade the remove operation to the orphaned customer entity when it is removed from the relationship:

@OneToMany(mappedBy="customer", orphanRemoval="true")
public List getOrders() { ... }