DEV Community: Adhiraj Kinlekar

Inheritance vs Composition vs Aggregation

Adhiraj Kinlekar — Fri, 19 Jan 2024 14:03:50 +0000

The process of forming relations among entities is a crucial aspect of system design, playing a pivotal role in shaping the overall structure and functionality of a system. In the context of system design, entities represent distinct objects or concepts within the domain of the system.

To facilitate a deeper understanding of these relationships, let's explore the concept of association. Association is a technique for creating relationships between classes, where one class contains a reference to another class or object. This concept is fundamental to how entities interact, communicate, or collaborate within the system.

Aggregation

Aggregation is a weak form of association, where the contained class can exist independently of the containing class. The containing class is said to have a "has-a" relationship with the contained class.

In the given example, the Engine object is not "owned" by the Car class; rather, it's passed to the Car class through its constructor. The Car class simply holds a reference to the Engine object. The Car class doesn't control the Engine object's lifecycle. If the Car is destroyed, the Engine can still exist independently.

    public class Car 
    {
        private readonly Engine engine;

        public Car(Engine engine) { this.engine = engine; }

        public void Move() { engine.Start(); }

        public void Stop() { engine.Stop(); }
    };

    public class Engine
    {
        public void Start() { /* code to start the engine */ }

        public void Stop() { /* code to stop the engine */ }
    };

Composition

Composition, on the other hand, is a stronger form of association, where one class contains a reference to another class, and the contained class cannot exist independently of the containing class.

The containing class is said to have a "part-of" relationship with the contained class. For example, the Address class is associated with a particular user and cannot exist independently.

In composition, the class object's life cycle is fully controlled by the containing class, meaning when the containing class is destroyed, so is the contained class.

    public class User
    {
        private readonly string name;

        private readonly Address address;

        public User(string _name, int houseNo, string city, string state) { 

            name = _name;

            address = new Address(houseNo, city, state);
        }

        public string GetBasicUserInfo()
        {
            return name + " " + address.state;
        }
    };

    public class Address
    {
        public readonly int houseNo;

        public readonly string city;

        public readonly string state;

        public Address(int _houseNo, string _city, string _state)
        {
            houseNo = _houseNo;

            city = _city;

            state = _state;
        }
    };

Inheritance

Another related concept in forming relationships is inheritance. Inheritance is a fundamental concept in object-oriented programming (OOP) that allows a class (called a subclass or derived class) to acquire properties and behaviors (fields and methods) from another class (called a superclass or base class).

Inheritance establishes an "is-a" relationship between the base class and the derived class. For example, if you have a base class User and a derived class Employee, you can say that "an employee is a user".

    public class Employee : User
    {
        public readonly int employeeId;

        public Employee(int _employeeId, string _name, int houseNo, string city, string state) : base(_name, houseNo, city, state)
        {

            employeeId = _employeeId;
        }
    }

In conclusion, the establishment of relationships among entities is at the core of effective system design. By defining connections and associations, we enable entities to interact, communicate, and collaborate within the system. It's crucial to recognize that the way entities are related has a profound impact on the system's efficiency, data integrity, and overall performance.

Song of the day: The Dear Hunter - The Most Cursed of Hands / Who Am I

What makes a database ACID compliant?🧪

Adhiraj Kinlekar — Mon, 20 Nov 2023 08:45:38 +0000

Database Transactions

A database transaction is a logical unit of work comprising one or more operations. It ensures that all statements are executed completely; in the event of a failure, any partial changes are rolled back to maintain data integrity.

Transactions are not limited to write operations; they can also be read only, where only data retrieval (e.g., SELECT queries) is performed. Regardless of whether the operation is read or write, SQL Server treats each statement as its own transaction by default, committing it if successful or rolling it back if it fails.


-- *A basic MSSQL transaction example that ensures an order is fully created, or rolls back all changes if any system or user generated error occurs.*

-- READ COMMITTED is the default isolation level in SQL Server; setting it is optional and shown for clarity
-- Higher isolation levels are not required for this single-row atomic UPDATE (no range or read-before-write)
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

-- Transaction with TRY...CATCH  
BEGIN TRY  
    BEGIN TRANSACTION;  

    -- To prevent "hangs" during simultaneous checkouts, you can use WITH (ROWLOCK, READPAST) 
    -- to skip rows currently locked by other users instead of waiting.
    -- Note: Production logic may need to handle inventory shortages in a single row by iterating across multiple rows to fulfill the total quantity requested.
    UPDATE TOP (1) Inventory 
    SET Quantity = Quantity - 1 
    WHERE ProductId = 101 AND Quantity > 0
    ORDER BY ExpiryDate ASC; -- Deduct from oldest stock first

    -- Check if update happened  
    IF @@ROWCOUNT = 0  
        THROW 50001, 'Out of stock', 1;  

    -- Create order  
    INSERT INTO Orders (ProductId, OrderDate)  
    VALUES (101, GETDATE());  

    COMMIT TRANSACTION;  
END TRY  

BEGIN CATCH  
    IF @@TRANCOUNT > 0  
        ROLLBACK TRANSACTION;  

    PRINT 'Error: ' + ERROR_MESSAGE();  
END CATCH;

ACID Compliance

ACID compliance means that a database follows a set of rules to ensure transactions are processed reliably and safely. An ACID-compliant database guarantees that transactions behave correctly, data remains accurate, and failures or crashes do not corrupt data.

The 4 ACID properties as are follows -

Atomicity

Atomicity Ensures that a transaction does not leave the database in a partial state. Either all operations are successfully applied, or none are, and any intermediate changes are rolled back in case of failure.
The core of Atomicity is the Transaction Log (or Write-Ahead Log). Before any data is actually changed in the main database files, the system records the intended changes in a log.

Commit: If every step in the transaction block finishes without error, the database "commits," making the changes permanent.
Rollback: If a single step fails (due to a power outage, a crash, or a constraint violation), the database uses the log to "undo" any partial changes, returning the data to its exact state before the transaction started.

Example -
Imagine a customer placing an order for 5 units of a specific product. To complete this transaction accurately and prevent overselling, the system must perform two distinct operations in a strict sequence:

Inventory Deduction: Subtract 5 units from the Products table to secure the stock for this specific customer.
Order Creation: Insert a new record into the Orders table to officially document the purchase and customer details.

The absence of Atomicity in this scenario can lead to critical data discrepancies, such as "Missing Stock," where a system crash occurring after the Inventory Deduction but before the Order Creation results in 5 units being removed from the available inventory without a corresponding order record to account for them. This failure leaves the database in an inconsistent state where your digital records reflect a lower stock level than what is physically present in the warehouse.

Consistency

Consistency ensures that a transaction brings the database from one valid state to another. All data written must follow the rules and constraints defined by the schema, such as data types, domain constraints, and referential integrity. If any operation violates these rules, the transaction is rejected or rolled back to prevent invalid data.

Examples:

Unique Constraints: A transaction must fail if it attempts to register a user with an email address that already exists in the database.
Foreign Keys: An order cannot be saved if it references a CustomerID that does not exist in the Customers table.
Data Types: An update will be rejected if it tries to insert a string of text into a column defined strictly for integers.
Balance Minimums: A withdrawal transaction must roll back if the resulting account balance would drop below the allowed minimum of $0. While databases can enforce simple checks, ensuring a withdrawal doesn't drop a balance below $0 is typically a matter of Application Logic enforced by the developer.

Apart from constraints, for a transaction to be consistent, it must not leave the database in an an inconsistent or corrupted state. To ensure this, transactions must be atomic—meaning all parts of the transaction succeed or the entire operation is rolled back—and isolated from each other, so that concurrent operations do not interfere with each other.

Isolation

Isolation refers to the ability to concurrently process multiple transactions in a way that one does not affect another. Changes occurring in a particular transaction will not be visible to any other transaction until that particular change in that transaction is written to memory or has been committed.

Database Transaction Phenomena

Database phenomena occur when concurrent transactions—multiple actions happening at once—interact in ways that lead to inconsistent or "incorrect" data. The degree to which a database prevents these phenomena is what defines its Isolation Level.

The four primary phenomena are:

Dirty Read : A Dirty read is a situation when a transaction reads data that has not yet been committed.
Non-Repeatable Read : A Non-Repeatable Read Occurs when a transaction reads the same row multiple times and gets different values. Even though each read returns only committed data, if another transaction modifies and commits the data between the reads, the subsequent read will return a different value.
Phantom Read: A phantom read occurs when a transaction executes a query that reads rows matching a specific condition. If, between subsequent reads, another transaction inserts or deletes rows that meet that same condition, the result set changes. As a result, the transaction encounters "phantom" rows that were not present—or have disappeared—since the initial read.
Lost Update: A lost update occurs when two concurrent transactions read the same record and then both attempt to update it based on the value they originally read. Because the second transaction is unaware of the first transaction's changes, it overwrites the first update, causing that data to be permanently lost.

Isolation Levels

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

Read Uncommitted : Read Uncommitted is the lowest level of transaction isolation. In this level, a transaction can read data modifications made by other transactions even before they are committed, leading to Dirty Reads. At this level, transactions are effectively not isolated from one another. Consequently, it provides no protection against Dirty Reads, Non-Repeatable Reads, or Phantom Reads, and it remains highly susceptible to Lost Updates.
Read Committed : Read Committed is the default isolation level for many popular database systems, such as PostgreSQL and SQL Server. It guarantees that any data read by a transaction has been fully committed at the moment it is read, effectively preventing Dirty Reads. Under this level, the system ensures that a transaction never sees "in-progress" or uncommitted changes from others. However, because Read Committed uses short-lived read (shared) locks that are released as soon as the data is read, other transactions are free to update or delete those rows immediately after the read operation completes. Consequently, this level does not prevent Non-Repeatable Reads or Phantom Reads. It also remains susceptible to Lost Updates because a transaction can read a value and later overwrite it without realizing another transaction modified it in between. A standard way to prevent lost updates without needing higher isolation levels is through Atomic Updates, which handle the logic in a single SQL statement.

   -- Atomic update that prevents lost updates and enforces business logic in one step
    UPDATE Inventory 
    SET Quantity = Quantity - 5 
    WHERE ProductId = 101 
    AND Quantity >= 5; -- The WHERE clause ensures Application Consistency (no negative stock)

Repeatable Read is a highly restrictive isolation level that ensures any data you read once will remain exactly the same if you read it again within the same transaction. To achieve this, the transaction typically holds Long-lived Shared Locks on all referenced rows until the transaction commits. This prevents other transactions from updating or deleting those rows until the transaction completes. This effectively eliminates Dirty Reads and Non-Repeatable Reads and helps prevent Lost Updates. However, because it does not lock all possible relevant rows, Phantom Reads are still possible.

    -- This locks the existing rows (ProductIDs 1, 2, 3) for CategoryID 5, preventing updates or deletes.
    -- It does NOT lock the "index range," so others can still insert a new ProductID 4 into that category.
    SELECT * FROM Products WHERE CategoryID = 5;

Serializable : Serializable is the highest and most restrictive isolation level. It guarantees that the final result of concurrent transactions is exactly the same as if they had been executed serially (one after another). However, in practice, the database does not literally stop all other queries to run them one by one. Instead, the database uses Range Locking (or Predicate Locking) to "lock the territory" of a query. This doesn't just protect the rows you can see; it extends protection to the entire range defined by your query's criteria. This prevents any other transaction from inserting, updating, or deleting any data, including data that doesn't exist yet that would fall within that range until your transaction is complete. While it provides the strongest guarantee of data integrity, it comes with a significant performance cost because it locks entire ranges of data.
Snapshot Isolation : Snapshot Isolation ensures that each query in a transaction sees only the data that was committed at the start of that transaction. It functions like a consistent "snapshot" or version of the database captured at a specific point in time. Snapshot isolation is frequently used to critique the ANSI SQL-92 standard's definition of isolation levels as it exhibits none of the three primary 'anomalies' prohibited by the SQL standard (Dirty Reads, Non-Repeatable Reads, and Phantom Reads), without incurring the performance cost of a strictly Serializable implementation. While snapshot isolation prevents most common concurrency issues, it's worth noting that it differs from true serializable isolation in that it remains vulnerable to a phenomenon called write skew. A technical deep-dive into write skew reveals how business rules can be violated even when no direct row-level conflict occurs. In a scenario where two doctors are on call and the rule is "at least one must be on call," Doctor A may see that Doctor B is on call and sign off. Simultaneously, Doctor B sees that Doctor A is on call and signs off. Because both transactions read from a "snapshot" where both were present, the final state leaves zero doctors on call—violating the rule despite neither transaction directly modifying the same record at the same time. In this case, the records being modified are the individual availability statuses for Doctor A and Doctor B; because they update different rows, the database does not detect a conflict, even though their combined actions break the business logic. To prevent this issue, you can use the highest isolation level, Serializable, which ensures the final result of concurrent transactions is exactly the same as if they had been executed one after another, effectively eliminating the possibility of a "phantom" change or a logical conflict. Alternatively, you can use Pessimistic Locking through explicit locks to block other transactions from modifying the relevant rows until your transaction is complete. Finally, you may Materialize Conflicts by forcing both transactions to update a shared "parent" record, such as a Shift or Department row, which triggers the database's internal conflict detection mechanisms and forces one of the transactions to wait or fail.

It is worth noting that isolation levels do differ from database to database, as each DBMS may implement them differently and even choose different default levels, resulting in variations in how concurrency issues like dirty reads or phantom reads are handled.

Durability

Durability ensures that once a transaction is committed, its changes are permanently recorded in non-volatile storage (such as an HDD or SSD). This guarantees that data survives system failures, including software crashes or power outages. Once the system restarts, all committed data remains intact and accessible.

Implementation Methods

Database systems typically use one or a combination of the following techniques to ensure durability:

Write-Ahead Logging (WAL): Before any changes are applied to the actual database files, they are recorded in a dedicated log on disk. If a crash occurs, the system "replays" this log to restore the database to its last consistent state.
Snapshotting (Checkpointing): The entire state of the database is periodically saved to disk as a point-in-time image. While this allows for fast recovery, any data modified between snapshots may be lost unless it is paired with a logging mechanism.
Append-Only File (AOF): Every write operation is appended to a continuous log file. To recover, the database simply re-executes the sequence of operations in the file to reconstruct the data set.
Replication: Data is copied across multiple physical machines to ensure that a hardware failure on one node does not result in total data loss.

Isolation Level	Read Strategy / Locking	Write (Exclusive) Locks	Scope of Lock	Dirty Reads	Non-Repeatable Reads	Phantoms	Lost Updates
Read Uncommitted	No Locks. Reads "live" uncommitted data.	Held until Commit.	Individual rows.	May occur	May occur	May occur	May occur
Read Committed	Short-lived. Locks released immediately (or versioned).	Held until Commit.	Individual rows.	No	May occur	May occur	May occur
Repeatable Read	Long-lived. Read locks held on rows until Commit.	Held until Commit.	Individual referenced rows.	No	No	May occur	No
Serializable	Range Locking. Locks all rows and gaps.	Held until Commit.	Entire range of the query.	No	No	No	No
Snapshot	Versioned. Reads from a "snapshot" at start.	Held until Commit.	Individual rows.	No	No	No	No

Concurrency Control

Concurrency Control is the management procedure required to coordinate the simultaneous execution of transactions in a database. Its primary goal is to ensure data integrity and consistency when multiple users access the same data at the same time. This is typically achieved through two main strategies: Optimistic and Pessimistic concurrency.

Optimistic Concurrency Control

Optimistic Concurrency Control works by tracking the version of the data being modified rather than applying immediate locks. Instead of blocking other users, the system allows transactions to proceed independently and only checks for conflicts right before the changes are committed to the database. If it is discovered that another transaction changed the data while the current one was still processing, a conflict is detected, the transaction fails by rolling back, and the application must then retry the operation. This approach scales significantly better for applications with many users and high read-to-write ratios because it completely avoids the performance overhead associated with managing complex locks.

A common implementation of these optimistic principles is Snapshot Isolation, which allows a transaction to see a consistent "snapshot" of the data as it existed at the moment the transaction started. This mechanism enables reads and writes to occur simultaneously without blocking one another, typically utilizing internal row-versioning to detect and resolve any write-write conflicts during the final merge.

Pessimistic Concurrency Control

Pessimistic Concurrency Control assumes that conflicts between transactions are likely to happen and therefore blocks data records as soon as a user starts an update. Under this model, other users are unable to update or, in some cases, even read the data until the original lock is released. While this approach prevents the "wasted work" of a transaction failing at the very end, it can limit scalability and lead to performance bottlenecks if many users are competing for the same records. To manage these interactions, the system uses specific lock modes:

Shared Lock (S): Also known as a Read Lock, it allows multiple transactions to read a resource simultaneously but prevents any writing.
Exclusive Lock (X): Also known as a Write Lock, it is held by only one transaction and blocks all others from both reading and writing.
Update Lock (U): Acts as a precursor to an exclusive lock; it allows others to read the data but ensures only one transaction is "queued" to perform an update, which helps prevent deadlocks.

Song of the day: Dream Theater - Pull Me Under

Git Essentials: A Pragmatic Approach to Version Control 🌿

Adhiraj Kinlekar — Sun, 12 Nov 2023 19:24:50 +0000

Introduction to Version Control

👋 To understand Git, having a foundational understanding of version control is essential. Version control, also known as source control, is the practice of tracking and managing changes to files over time. Version control systems are software tools that help software developers work in a team by enabling efficient collaboration and effectively managing changes to files in projects. By far, Git is the most widely used version control system in the world today.

Introduction to Git

Git is an open-source distributed version control software originally developed in 2005 by Linus Torvalds. To get started with Git, download and install it from git-scm.com. During installation, use the recommended settings and optionally select a default editor of your choice. Once installed, the next step is to create a Git repository.

Creating a Git Repository

A Git repository is a directory whose contents are tracked by Git. As a good practice, always execute git status to confirm you are not currently within an existing repository before initializing one. Utilize the git init command to create a new Git repository or convert an untracked project into one.

Working with remote Repositories

Git repositories can be either local or remote. When collaborating on an existing project hosted on a remote server, you can duplicate the repository in your local directory. The process of creating this local copy is known as cloning. Here's an example:

git clone https://github.com/facebook/react.git

Staging and Committing changes

Once your repository is cloned or initialized, add a file or make some changes to existing files to understand some of the most important concepts in Git, staging and committing.

Committing: Saving a Snapshot of Your Codebase

Staging is a step that comes before committing, but before diving into it, it's helpful to first understand what committing entails and what problems it addresses.

Imagine investing considerable time and effort into developing a feature, only to encounter an unexpected event just before completion, potentially resulting in the loss of your code changes. While periodic file-saving provides some protection, it may not be foolproof. This is where Git comes into play. Committing in Git serves as a mechanism to save and undo changes as well as offers the ability to restore previous code versions.

Committing essentially acts like taking a snapshot of your codebase at a specific moment. By committing changes, you create a record of your codebase's state, providing a reference point for future use. This practice ensures the safety and recoverability of your work, allowing you to navigate through different versions of your codebase with confidence

Staging: The Pre-commit Step

So, where does staging fit into this? 🤔 Staging plays a crucial role in the Git workflow, enabling you to specify which local changes should be included in the next commit. When you stage changes, you effectively add modified files to the staging area, preparing them for inclusion in a commit.

It's essential to understand that staging itself does not make any permanent changes to the repository—only committing records the changes permanently. To maintain clear and organized commits, it's a good practice to group related changes together when committing.

Here's an example of adding a file to the staging area and performing a commit with a message:

// Add a file to the staging area
   git add <filename>

// To commit the changes to the repository with a message
   git commit -m "Added a new file to the project"

Branching in Git

One of the most important features of a version control system is its capability to create branches, allowing developers to simultaneously work on different versions of the code.

A branch represents a distinct version of the codebase derived from a specific point in the repository's history. This new version, essentially a snapshot of the code at the time of branching, enables developers to work on new features, experiment with code changes, or address bugs without impacting the main codebase until ready for integration.

The master branch is the default branch created upon initializing a repository. Typically, it functions as the primary branch where all changes eventually merge from other branches. While the master branch is commonly employed for production code, its usage can vary based on the team's development workflow and practices.

The git branch command offers various functionalities, including creating, listing, renaming, and deleting branches. To create a new branch based on the current working branch, simply execute the following command:

git branch branch-name

Navigating between branches

The git checkout command provides a way to switch between branches. However, it's worth noting that this command has multiple uses, and hence it is a good practice to use the newer, safer and appropriately named git switch command.


git checkout feature-branch

git switch feature-branch

Now let's see how we can navigate between branches without having to discard local changes…

Stashing

Stashing is used to record the current state of the working directory and go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit.

Quick note - (In Git, the HEAD typically points to the latest commit on the currently checked-out branch. In a detached HEAD state, it directly references a specific commit rather than a branch. To reattach the HEAD, simply switch to a branch. To discard changes made in this state, checkout to an existing branch. Commits in a detached HEAD state won't impact the existing branch and are archived by Git. To retain changes, create a new branch, and the HEAD will no longer be detached)

Stashing is handy when you need to quickly switch between branches and work on something else, but you're mid-way through a code change and aren't quite ready to commit. A commit is part of the public Git history, meaning that other collaborators can see your commits when they fetch or pull changes from the repository. In contrast, a stash is stored locally on your machine and is not automatically shared with others.

The most common git stash options include:

git stash push // creates a new stash, rolling back file states.

git stash pop // restores stash files to the workspace and deletes the stash.

git stash apply // restores stash files to the workspace without deleting the stash.

git stash list // shows stash history chronologically.

git stash clear // removes all stash entries.

Undoing and managing history

Git provides multiple ways to view and amend history. You might want to amend history in case something goes wrong or if you want to clean up unnecessary commits and have a clean history.

Git restore

The git restore command is used to unstage or discard uncommitted local changes. It can undo the effects of git add with the --staged argument, allowing you to unstage changes previously added to the Staging Area. Additionally, it can discard local changes in a file, reverting it to its last committed state."

Git reset

The git reset command resets the repository back to the specified commit. Changes from commits since the specified commit will be preserved as unstaged changes, allowing you to take further action as needed. It also offers a more forceful option, --hard commit-hash, which not only removes commit entries but also discards all changes made since the specified commit.

Git revert

Another useful command related to undoing history is the git revert command. It creates a brand new commit that reverses the changes from the provided commit. For this reason, git revert is commonly recommended for undoing changes on a public branch to avoid confusion and potential conflicts when pulling changes. On the other hand, git reset should be reserved for undoing changes on a private branch.

Collaborating with other developers

In a professional environment, your source code is likely to be stored in a remote repository that is connected to your local repository. Remote repositories are hosted on platforms like GitHub, GitLab etc. Developers work together by regularly pushing and pulling changes to and from the remote repository. This allows multiple people to work on the same codebase and share their contributions. The remote repository acts as a central location for the team to keep their code and collaborate efficiently.

Git Push

Pushing is the process of uploading the content of a local repository to a remote repository. It facilitates the transfer of commits from a local repository to a corresponding remote one, such as on GitHub. Git allows you to set the upstream of the branch being pushed, creating a linkage between the local branch and its counterpart on the remote repository. Once the upstream is established for a branch, you can conveniently use a shorthand command to push the current branch to its upstream, eliminating the need to specify the remote or branch explicitly.

Quick note - (Upstream refers to the original repository or branch from which a clone or fork was created. For example, when you clone a repository from GitHub, the remote GitHub repository is considered the upstream for the local copy. Pushing changes to a branch that doesn't exist remotely creates a new branch on the upstream repository. The terms 'origin' and 'upstream' are interchangeable, representing the repository from which the project was cloned. Typically, 'origin' is set as the default remote name during cloning, but it's a convention and can be customized to any preferred name)

Here is an example of how to push commits to a remote repository, set the upstream of the branch, and use the shorthand command:

# Push local commits to the remote repository
git push <remote> <branch>

# Set the upstream of the branch
git push -u <remote> <branch>

# Push to the upstream using shorthand
git push

Git Pull

The git pull command is used to download commits and other changes from a remote repository and immediately update the local repository to match that content. It's a common task in collaborative Git-based workflows, as it allows you to synchronize your local repository with the remote one.

When you use git pull, git will try to merge the changes automatically. But if there are conflicts between the local and remote changes, it will stop the process and ask you to resolve the conflicts before proceeding with the merge.

It's considered a good practice to pull the changes from the remote repository before pushing your own changes. This way you'll avoid conflicts and ensure that your local repository is up-to-date with the remote one.

Git Fetch

The git fetch command downloads commits, files, and references from a remote repository. However, these changes are not immediately integrated into the working files. To view the downloaded content, you must explicitly switch to the specific remote branch.

Fetching provides a way to safely review commits without automatically merging them into your local repository, as opposed to the git pull command, which combines git fetch with git merge to automatically integrate changes into your local branch.

Here is an example of how to fetch commits from a remote repository and review the changes:

# Fetch commits from the remote repository
git fetch origin feature

# Check out the fetched branch
git checkout origin/feature

Merging and Rebasing branches

Merging

Merging serves as a method to combine branches and their respective histories, a common practice in Git, especially in workflows like the feature branch model. In this approach, developers create a new branch for each feature, enabling them to work on the feature independently of the main development line.

Throughout development, updates from the primary branch, often named main or master, are regularly merged into the feature branch, ensuring it stays current with the latest changes.

Upon completing the feature, the feature branch undergoes a merge back into the primary branch, integrating the changes into the main development line.

Merge commits are distinctive, having two parent commits—one from the current branch and the other from the branch being merged. Git attempts to automatically merge the separate histories during a merge commit. However, if a merge conflict arises, indicating conflicting changes in both histories, Git requires user intervention to resolve the conflict.

Rebasing

Rebasing, a specialized Git utility, enhances the integration of changes between branches, offering an alternative to merging.

The process involves moving or "replaying" a sequence of commits from one branch onto the tip of another. By updating the target branch with the latest commits from the source, it effectively "replays" these commits on top of the target branch, facilitating the incorporation of new changes while maintaining a linear history.

In the context of a feature branching workflow, git rebase is particularly valuable. It enables the integration of changes from the main branch into a feature branch, preserving a linear commit history. This choice over git merge aids in presenting a clearer development flow without generating additional merge commits.

It's essential to note that rebasing alters commit history, making it advisable to avoid if the branch has been shared or if changes have been pushed to a public branch.

Rebasing also provides the flexibility to add or drop commits before a specified commit hash. When executed in interactive mode, Git opens a text editor, displaying a list of commits within the specified range and a set of commands (pick, reword, edit, squash, and drop) for user selection.

GitHub and contributing to open source

GitHub is a platform that hosts your repositories and aids in collaboration on software projects. GitHub provides you with a safe space to store your code so that even in a worst-case scenario such as a system failure, you will always have a backup of your code base.

Pull Request

A pull request is a feature provided by GitHub (and other web-based Git hosting services), it is not a native feature of Git. A pull request enables you to notify others about changes that you have pushed to a branch in a repository and request that they merge your changes into the main branch.

Upon opening a pull request, you can include a description of the changes and the rationale behind them. Collaborators on the repository have the opportunity to review the proposed modifications, engage in discussions, and leave comments. While the pull request is active, you can continue making additional commits to the branch to address any feedback received.

Pull request is a powerful feature that allows developers to collaborate and review code changes before they are merged into the main branch. It's often used in Git-based workflows to facilitate code review, testing and quality assurance processes.

Forking

A fork is a copy of a repository that you have control over, it can be thought of as your own personal version of the original repository. Forks allow you to make changes to a project without affecting the original repository.

In most cases, open-source projects do not allow contributors to push changes directly to the original repository. Instead, contributors are expected to fork the repository, make changes to their own copy, and then submit a pull request to the maintainers of the original repository.

When you fork a repository on GitHub, it creates a copy of the repository under your own account, which you can then clone to your local machine. Once you've cloned the repository, you will need to add another remote to your local copy, this remote should point to the original repository that you cloned from. This is necessary so that you can fetch the latest commits from the original repository and keep your fork up-to-date.

You can then make changes to your local copy of the repository, commit your changes, and push them to your fork on GitHub. Once you're ready to submit your changes, you can create a pull request to request that the maintainers of the original repository review and merge your changes.

The following example demonstrates how to add a new remote named upstream that points to the original repository:

git remote add upstream https://github.com/facebook/react.git

PS - The cover image features a dog playing fetch with a branch (twig). Get it?

Resources :
https://git-scm.com/book/en/v2
https://nvie.com/posts/a-successful-git-branching-model/
https://www.atlassian.com/git/tutorials/comparing-workflows

Song of the day : Saturnus - I long

Understanding Keys in Relational Databases 🔑

Adhiraj Kinlekar — Sun, 12 Nov 2023 04:45:14 +0000

Keys are used to uniquely identify records or rows of data in a table or to establish and identify relationships between tables. Mainly, there are eight different keys in relational databases.

Super key : A Super key is any combination of columns that can be used to uniquely identify a row.
Candidate key : A Candidate Key is the minimal amount of columns that can be used to uniquely identify a row. All super keys can’t be candidate keys but any candidate key can be a super key.
Primary key : A Primary key is a key which uniquely identifies a row. Out of all the Candidate keys that are possible for a table, there can be only one key that can be used as a Primary Key. In other words, a Primary key is the Candidate key selected by the database administrator to uniquely identify rows in a table. A primary key cannot have null or duplicate values.
Alternate key : A candidate key which is not selected as a primary key is called an alternate or a secondary key.
Surrogate key : A surrogate key is a key which is a primary key but the column on which the key is applied is unrelated to the data present in the table. An example of a surrogate key would an auto incrementing Id column which is marked as a primary key.
Composite key : A table can have only one primary key, which may consist of single or multiple fields. When multiple fields are used as a primary key, it is called a composite key.
Foreign key : A foreign key is a column in the table that is the primary key in another table. It is useful for drawing relations between the tables.
Compound key : A compound key is similar to a composite key in that two or more fields are used to uniquely identify a row. However, a compound key is formed when a foreign key is involved in the distinctive identification.

Out of all the keys, three play a significant role in designing a well-organized and robust database system: the primary key, which uniquely identifies records; the foreign key, which establishes relationships between tables; and, while not always chosen as the primary key, candidate keys are vital because they represent the minimal set of columns that can uniquely identify a row.

Song of the day : Cynic - How could I

Understanding the four Pillars of Object-Oriented Programming using JavaScript 💊

Adhiraj Kinlekar — Sat, 11 Nov 2023 08:49:07 +0000

Object Oriented Programming

Object-Oriented Programming is a programming paradigm that enables you to model and structure your code using objects and classes. JavaScript is not a full-fledged OOP language, but you can still leverage OOP's core principles to write cleaner and more maintainable code. There are four main pillars of Object-Oriented Programming:

Abstraction

Abstraction means hiding the complex implementation details and exposing only what is necessary. Even though JavaScript lacks interfaces or abstract classes, we can still achieve abstraction through other means.

One effective approach for implementing abstraction is to expose only the necessary methods and then, through this exposed method, invoke the private methods of the class. This strategy effectively conceals the underlying complexities, which is a fundamental aspect of abstraction.

class Auth {

    constructor() {}

    #validate() {
    // Private method
    }

    #sendOnboardingEmail() {
    // Private method
    }

    // Public method that calls private methods
    signUp() {
      this.#validate();
      // Execute signUp functionality
      this.#sendOnboardingEmail();
    }
}

const auth = new Auth();

// Calls the public method, which, in turn, calls private methods
auth.signUp();

Encapsulation

When you search the internet for information about Abstraction and Encapsulation, you will likely come across numerous articles that sometimes present conflicting ideas. In my understanding, although abstraction and encapsulation are different concepts, they often complement each other. In the code block above, private accessors are utilized, enabling controlled access to the class, aligning with the principles of Encapsulation. Encapsulation promotes the idea of bundling data and the functions that operate on that data into a single, self-contained package. This encapsulated entity can control how the data is accessed, modified, or interacted with.

Even though Encapsulation is an OOP concept, it can be implemented without the use of classes and objects by utilizing Closures. A closure is a mechanism that enables an inner function to access the variables and parameters of its outer function, even after the outer function has completed its execution. Closures achieve encapsulation by packaging the actual code (the body of the function) along with the variables and parameters that the function can access during its execution. The exclusive method for accessing the encapsulated data is through the function.

function createCounter() {

  let count = 0; // This variable is encapsulated within the closure.

  function increment() {
    count++; // The inner function can access the 'count' variable.
    console.log(count)
  }

  return increment; // Return the inner function (closure).
}

const counter = createCounter();

Inheritance

When a class acquires the members and behaviors of its parent class, it is known as Inheritance. Inheritance provides code reusability and encourages modular design by breaking down a complex system into smaller, manageable components. When you need to make changes or updates to shared functionality, you can do so in the base class. These changes automatically apply to all derived classes, reducing maintenance efforts and ensuring consistency throughout your codebase.

class Person {

  constructor(name, age) {
    this.name = name;
    this.age = age;
  }

  sayHello() {
    console.log(`Hello, my name is ${this.name}, and I am ${this.age} years old.`);
  }
}

// Create a derived class Student that inherits from Person
class Student extends Person {

  constructor(name, age, studentId) {
    super(name, age); // Call the parent class constructor using super
    this.studentId = studentId;
  }

  study(subject) {
    console.log(`${this.name} with student ID ${this.studentId} is studying ${subject}.`);
  }
}

// Create instances of Person and Student
const person1 = new Person('Alice', 30);

const student1 = new Student('Bob', 25, '12345');

// Use the inherited methods
person1.sayHello();

student1.sayHello();

student1.study('Math');

Polymorphism

The term 'polymorphism' means having many forms. The concept of polymorphism enables us to perform different operations in various scenarios. In object-oriented programming languages such as C#, polymorphism is achieved through the use of interfaces and abstract classes, as well as through the use of virtual methods and overriding in inheritance. While JavaScript does not provide comprehensive support for polymorphism, we can still achieve it.

Polymorphism can be attained by using inheritance and by overriding the base class. You do not need to explicitly indicate that a method is being overridden since JavaScript uses a prototype-based inheritance model, and method overriding is accomplished simply by defining a method with the same name in a subclass. The new method in the subclass effectively replaces the method with the same name in the base class, allowing you to perform different actions in different scenarios, which aligns with the concept of polymorphism

class Transport {

  constructor() {}

  drive() {
    console.log("Driving...");
  }

  fly() {
    console.log("Flying...");
  }
}

// Create a derived class Car that inherits from Transport
class Car extends Transport {

  constructor() {
    super();
  }

// Overrides it's base implementation
  fly() {
    console.log("I am a car, I cannot fly");
  }
}

const audi = new Car();

audi.fly();

Song of the day : Agalloch - Hawthorne Passage