PostgreSQL's Foreign Data Wrapper (FDW)

PostgreSQL's Foreign Data Wrapper (FDW) extension and its capabilities for accessing remote databases. FDW provides a standard method for connecting to and querying tables in different databases as if they were part of the local database. This feature is particularly useful for integrating data across multiple PostgreSQL instances or accessing data from different servers.

What is FDW?

Foreign Data Wrapper (FDW) is an extension in PostgreSQL designed to connect to external data sources. With FDW, users can perform operations on remote tables seamlessly, making it easier to integrate and analyze data across various systems.

How to Use FDW

Here's a concise guide on setting up and using FDW:

1. Install the FDW Extension: To enable FDW, the extension must be installed in the PostgreSQL database:

sql
   CREATE EXTENSION IF NOT EXISTS postgres_fdw;
   

2. Create a Foreign Server: Define the remote database connection details, including the host, port, and database name:

sql
   CREATE SERVER my_foreign_server
   FOREIGN DATA WRAPPER postgres_fdw
   OPTIONS (host 'your_host', port '5432', dbname 'remote_db');
   

3. Set Up User Mapping: Configure authentication details for accessing the remote server:

sql
   CREATE USER MAPPING FOR local_user
   SERVER my_foreign_server
   OPTIONS (user 'remote_user', password 'remote_password');
   

4. Create Foreign Tables: Define tables in the local database that map to the remote database tables:

sql
   CREATE FOREIGN TABLE foreign_table_name (
       column1 datatype,
       column2 datatype
       -- other columns
   )
   SERVER my_foreign_server
   OPTIONS (schema_name 'public', table_name 'remote_table');
   

5. Query the Foreign Tables: Query the foreign tables as if they were local tables:

sql
   SELECT * FROM foreign_table_name;
   

Example Use Case

For instance, if there are two databases on the same PostgreSQL server—sales_db and hr_db—FDW can be used to access employee data from hr_db while working within sales_db. This setup simplifies data integration and reporting across different databases.

FDW streamlines data access and management, providing a powerful tool for integrating and analyzing data from multiple sources within PostgreSQL.

#postgres #database #fdw

To make your Django application ASGI-compatible and run it with Daphne, follow these steps:

1. Install Daphne: Install Daphne if you haven't already:

   pip install daphne

2. Ensure ASGI Configuration: Your asgi.py file should look like this:

   import os
   from django.core.asgi import get_asgi_application

   os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'your_project_name.settings')

   application = get_asgi_application()

3. Update settings.py: Add the ASGI_APPLICATION setting to point to your ASGI application:

ASGI_APPLICATION = 'your_project_name.asgi.application'

Replace 'your_project_name.settings' with the path to your Django settings module.

4. Run Daphne: Start Daphne with your ASGI application using:

   daphne -u your_project_name.asgi:application

Alternatively, run it on a specific port:

   daphne -p 8000 your_project_name.asgi:application

This setup will get your Django application running with Daphne as the ASGI server.

#python #django #daphne

A Lambda layer in AWS Lambda is a feature that lets us manage and share common code and libraries across multiple Lambda functions. By creating a Lambda layer, we can package common code in its own module, which can then be used by our Lambda functions. This reduces duplication and simplifies the management of shared code.

We can generate a base64-encoded random key easily using either openssl or a combination of dd and base64. Here's how:

openssl rand -base64 32

Alternatively, using dd and base64:

dd if=/dev/urandom bs=32 count=1 2>/dev/null | base64

Both commands will give you a 32-byte random key encoded in base64.

#encryption #openssl

To rename a table in TypeORM, follow these steps:

• Create a new migration.

npx typeorm migration:create -n RenameTable

This will create a new migration file in the migrations directory

• Edit the Migration File:

import { MigrationInterface, QueryRunner } from "typeorm";

export class RenameTable1724826351040 implements MigrationInterface {

    public async up(queryRunner: QueryRunner): Promise<void> {
        await queryRunner.renameTable('old_table_name', 'new_table_name');

    }

    public async down(queryRunner: QueryRunner): Promise<void> {
        await queryRunner.renameTable('new_table_name', 'old_table_name');
    }

}

• Run the migration:

npm run typeorm -- migration:run

#typeorm #js

Handling Image Uploads with Active Storage in Rails

Active Storage simplifies file uploads in Rails by attaching files to models.

Setup: Install Active Storage and run rails active_storage:install and rails db:migrate to create necessary tables.

Model Configuration: Use has_many_attached :images to allow multiple image uploads in our model. Example:

class SomeModel < ApplicationRecord
  has_many_attached :images
end

Form: Ensure the form includes multipart: true and allows multiple file uploads with form.file_field :images, multiple: true.

Controller: Permit images in the strong parameters with images: []. Example:

def some_params
  params.require(:some_model).permit(:note, images: [])
end

Migration: Remove old image columns if switching from direct storage to Active Storage. <#CU6U0R822|> #activestorage #fileupload

To logout from Keycloak using the signOut function in NextAuth, you need to override the default behavior to ensure that the user is properly logged out from Keycloak as well. Here's how you can update your signOut function:

async signOut({ token }) {
  if (token.provider === "keycloak") {
    const issuerUrl = authOptions.providers.find((p) => p.id === "keycloak")
      .options!.issuer!;
    const logOutUrl = new URL(
      `${issuerUrl}/protocol/openid-connect/logout`
    );
    logOutUrl.searchParams.set("id_token_hint", token.id_token!);
    await fetch(logOutUrl);
  }
}

#keycloak #nextauth #nextjs #js

Delegating Permissions in Pundit:

I encountered a scenario where I needed to retrieve the scope of one policy and use it within another policy. Specifically, I wanted to delegate permissions from one policy to another.

To address this issue, I learned to use Pundit's methods for manually retrieving policies and scopes: • Retrieving a Policy

Pundit.policy(user, record)  # Returns nil if the policy does not exist
Pundit.policy!(user, record) # Raises an exception if the policy does not exist

• Retrieving a Policy Scope:

Pundit.policy_scope(user, ModelClass)  # Returns nil if the policy scope does not exist
Pundit.policy_scope!(user, ModelClass) # Raises an exception if the policy scope does not exist

These methods allowed me to delegate permissions effectively by retrieving and applying the appropriate scopes and policies

#rails #pundit #pundit-policy #authorization

Quick Tip: How can we open a PR from one repository to another repository

1. Create the branch in the current repo

git checkout -b new-branch

2. Add the destination repository as a remote.

git remote add destination <https://github.com/username/destination-repo.git>

3. Push the new branch to the destination repository

git push destination new-branch

4. To check all the remote repositories added, we can do:

 git remote -v

Then, we create a PR in the destination repository from the new branch. This process effectively copies the changes from the original PR into a new PR in a different repository.

#github #git

Rails templates accept any locals as arguments. However, starting from Rails 7.1, we can restrict which locals a template must accept using "Strict Locals".

// _search.html.erb

<# locals: (:url, :field_name, :placeholder) -%>

We can also set default values

<# locals: (placeholder: "Search", :url, :field_name) -%>

#rails