SOLID Principles

1) Single Responsibility Principle
 A class should have one, and only one, reason to change.

2) Open/Closed Principle
 Objects or entities should be open for extension, but closed for modification.

3) Liskov Substitution Principle  [LSP]
 Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.
 All this is stating is that every subclass/derived class should be substitutable for their base/parent class.
 In other words, as simple as that, a subclass should override the parent class methods in a way that does not break functionality from a client’s point of view.

4)Interface Segregation Principle
  A client should never be forced to implement an interface that it doesn’t use or clients shouldn’t be forced to depend on methods they do not use.
  [Have smaller interfaces instead of one big interface]

5) Dependency Inversion
Entities must depend on abstractions not on concretions. It states that the high level module must not depend on the low level module, but they should depend on abstractions. [Code for interface/abstract class instead of concrete classes]

ACID

A - Atomicity
    All or nothing
C - Consistency
    integirity - Correctnes of data must be maintained before and after the transaction.
I - Isolation
    Multiple transactions will be running without interfearance of each other until the commit (written to disk).
D-  Durability
     Once transaction is committed successfully then the transaction (data) must be written to permanent storage irrespective of system failures.

Transaction Isolation

Transaction Isolation Levels

As we know that, in order to maintain consistency in a database, it follows ACID properties. Among these four properties (Atomicity, Consistency, Isolation and Durability) Isolation determines how transaction integrity is visible to other users and systems. It means that a transaction should take place in a system in such a way that it is the only transaction that is accessing the resources in a database system.
Isolation levels defines the degree to which a transaction must be isolated from the data modifications made by any other transaction in the database system. A transaction isolation level are defined by the following phenomena –

• Dirty Read – A Dirty read is the situation when a transaction reads a data that has not yet been commited.For example, Let’s say transaction 1 updates a row and leaves it uncommited, meanwhile Transaction 2 reads the updated row. If transaction 1 rolls back the change, transaction 2 will have read data that is considered never to have existed.
• Non Repeatable read – Non Repeatable read occurs when a transaction reads same row twice, and get a different value each time. For example, suppose transaction T1 reads a data. Due to concurrency, another transaction T2 updates the same data and commit, Now if transaction T1 rereads the same data, it will retrieve a different value.
• Phantom Read – Phantom Read occurs when two same queries are executed, but the rows retrieved by the two, are different. For example, suppose transaction T1 retrieves a set of rows that satisfy some search criteria. Now, Transaction T2 generates some new rows that matches the search criteria for transaction T1. If transaction T1 reexecutes the statement that reads the rows, it gets a different set of rows this time.

Based on these phenomena, The SQL standard defines four isolation levels :

1. Read Uncommitted – Read Uncommitted is the lowest isolation level. In this level, one transaction may read not yet commited changes made by other transaction, thereby allowing dirty reads. In this level, transactions are not isolated from each other.
2. Read Committed – This isolation level guarantees that any data read is committed at the moment it is read. Thus it does not allows dirty read. The transaction hold a read or write lock on the current row, and thus prevent other rows from reading, updating or deleting it.
3. Repeatable Read – This is the most restrictive isolation level. The transaction holds read locks on all rows it references and write locks on all rows it inserts, updates, or deletes. Since other transaction cannot read, update or delete these rows, consequently it avoids non repeatable read.
4. Serializable – This is the Highest isolation level. A serializable execution is guaranteed to be serializable. Serializable execution is defined to be an execution of operations in which concurrently ececuting transactions appears to be serially executing.

The Table given below clearly depicts the relationship between isolation levels, read phenomena and locks :

Association is-A and has-A

                      Association

• IS-A relationship based on Inheritance, which can be of two types Class Inheritance or Interface Inheritance.
• Has-a relationship is composition relationship which is a productive way of code reuse.

Installing mysql on centos7

Versions:
 Mysql   : 5.7.23
 Centos : CentOS Linux release 7.4.1708 (Core)


1) Download mysql
 wget https://dev.mysql.com/get/mysql57-community-release-el7-9.noarch.rpm

2)Creating yum repository
 sudo rpm -ivh mysql57-community-release-el7-9.noarch.rpm

3)Install
  sudo yum install mysql-server

4)Starting mysql
  sudo systemctl start mysqld

5)Finding default password for root user
 On fresh installation default username will be 'root' and a temporary      password    will be automatically generated, that password
 can be found using following command 

 grep 'temporary password' /var/log/mysqld.log
 output:
  2018-08-14T08:49:40.599534Z 1 [Note] A temporary password is generated for root@localhost: ioOi9F#W8OM1

6)Reset the password
 Get into mysql console using following command [password from step-5]
 mysql -uroot -pioOi9F#W8OM1 

 Reset root password using following query
 alter user user() identified by 'desired_password'

 Thats all! Now you can play around with newly installed mysql in centos-7.