DEV Community: Daniel Lin

Some GORM Tips and Notes

Daniel Lin — Wed, 04 May 2022 16:05:22 +0000

There are some tips and GROM's notes might prevent you debugging in front of laptop all day.

Will not update the zero value

type User struct {
  ID int
  Age int
}
// if user.Age is 6 in database originally 
user.Age = 0
db.Updates(&user)

You will find the age is not updated.

How to solve

db.Model(&user).Select("*").Omit("Role").Update(User{Role: "admin", Age: 0})
db.Model(&user).Update(map[string]interface{}{"role": 0})

What is under the hood?

First, Most of generic in golang rely on reflect package. Gorm use reflect.IsZreo() to check if the field should be updated. source code
Second, 0 is zero value to int type, not zero value to interface{} type, because interface{} underneath is like a pointer to struct which saves object's type and reference. nil is the zero value for interface{}.

Therefore Gorm can only use Select(fields...) or map[stirng]interface{} to explicitly declare fields to be updated.

ErrNotFound

ErrNotFound will not happened in db.Find() function if not record found

WithContext

use WithContext so if the upstream ctx timeout or be cancelled the query can be cancelled too. https://gorm.io/docs/session.html#Context

timeoutCtx, _ := context.WithTimeout(context.Background(), time.Second)  

tx := db.WithContext(timeoutCtx)
tx.First(&user) // query with context timeoutCtx  
tx.Model(&user).Update("role", "admin") // update with context timeoutCtx

WithContext is a NewSession function type in GORM is safe to reuse in same context
https://gorm.io/docs/method_chaining.html#New-Session-Method

Method chaining

Method chaining sometime can make code more readable and more reusable. you can use pointer value to have some optional query parameters.

type Filter struct {
    IDs        []int
    Type       *OrderType
    UserID     *string
}

func (r *Repository) QueryOrders(ctx context.Context, filter Filter) (orders []repository.Order, err error) {
    db := r.db.WithContext(ctx)
    if filter.UserID != nil {
        db = db.Where("user_id = ?", filter.UserID)
    }
    if len(filter.IDs) > 0 {
        db = db.Where("id in (?)", filter.IDs)
    }
    if filter.Type != nil {
        db = db.Where("type = ?", filter.Type)
    }
    if err := db.Find(&orders).Error; err != nil {
        return nil, err
    }
}

but be careful Where is a Chaining Method in GORM the db returned by Where() is not safe to reuse.

Python Type Hint: Contravariant, Covariant, Invariant

Daniel Lin — Tue, 07 Dec 2021 17:33:35 +0000

We all know the Liskov substitution principle. The type can be replaced by its subtype without breaking it. But how about the relationship of their generic types, C[subtype] and C[type]?

So, what is covariant?

If A<: B, you can replace B with A anywhere
We say C[T] where T bound to B is

Contravariant, when A <: B => C[A] :> C[B]
We can replace C[B] with C[A] anywhere.
Covariant, when A <: B => C[A] <: C[B]
We can replace C[A] with C[B] anywhere. But How to cause this situation? I will explain in the example code below.
Invariant, If both circumstances do not suit. C[A] can not exchange with C[B], and vice versa.

Combine the concept with Sink / Source.

Accordingly to their behaviors, We have two kinds of objects defined.

Source[T]: It produces T, is covariant to T.
Sink[T]: It consumes T, is contravariant to T.

It is pretty abstract, so we directly move forward to the code below. Try to experiment by modifying according to comments.

import abc

from typing import Generic, TypeVar

class Base:
    def foo(self):
        print("foo")

class Derived(Base):
    def bar(self):
        print("bar")

First, we have Base and Derived. Derived is inherent from Base, so we have Derived <: Base.

T_co = TypeVar('T_co', bound='Base', covariant=True)

class Source(Generic[T_co]):
    @abc.abstractmethod
    def generate(self) -> T_co: # Produce T_co!
        pass

class SourceBase(Source[Base]):
    def generate(self) -> Derived: # Produce T_co!
        return Derived() 

class SourceDerived(Source[Derived]):
    def generate(self) -> Derived:
        return Derived() 

source: Source[Base] = SourceDerived()
source.generate()

#Try to uncomment lines below.
#source_derived: Source[Derived] = SourceBase()
#source_derived.generate()

Now, we have SourceDerived <: SourceBase. If we remove covariant=True, we will get this warning:

[Pyright reportGeneralTypeIssues] [E] Expression of type > "SourceDerived" cannot be assigned to declared type "Source[Base]"
TypeVar "T_co@Source" is invariant
"Derived" is incompatible with "Base"

If you modify covariant to contravariant, this is what happened. covariant tells the checker SourceDerived can be safely used anywhere we use SourceBase.

    def generate(self) -> T_co: <- warining
        pass

warining: [Pyright reportGeneralTypeIssues] [E] Contravariant type variable cannot be used in return type
TypeVar "T_co@Source" is contravariant

Look like covariant not only to check the place you use C[T_co] but also to check the method in C[T_co] return T_co.

Next, we take a look at the contravariant example.

T_contra = TypeVar('T_contra', bound='Base', contravariant=True)

class Sink(Generic[T_contra]):
    @abc.abstractmethod
    def consume(self, value: T_contra):
        pass

class SinkBase(Sink[Base]):
    def consume(self, value: Base):
        value.foo()

class SinkDerived(Sink[Derived]):
    def consume(self, value: Derived):
        value.bar()

    def other_func(self):
        pass

base = Base()
derived = Derived()
sink_derived: Sink[Derived] = SinkBase()
#we can safely consumer
sink_derived.consume(base)
sink_derived.consume(derived)
#Try to uncomment this line.
#sink_derived.other_func()

We have SinkDerive <: SinkBase here. Removing contravariant=True will get warning:

[Pyright reportGeneralTypeIssues] [E] Expression of type "SinkBase" cannot be assigned to declared type > "Sink[Derived]"
TypeVar "T_contra@Sink" is invariant
"Base" is incompatible with "Derived"

contravariant=True tells the static checker that the Base can be safely consumed Base or Derive type. Although we have annotated T_contra is contravariant, we will get an error if we call a method of Sink[Derived], sink_derived.other_func() for example, of course. Nevertheless, it is pretty common to assume that contravariant is opposite to covariant.

I think in most situations, we don't need to add contravariant or covariant right away. Only when the checker complains, do we look closely at the relationship of these generic types if used properly. If it is, we consider adding these hints, then.

2021 HITCON 紀念

Daniel Lin — Sat, 27 Nov 2021 11:11:39 +0000

今年第一次參加 HITCON ，因為演講聽不太懂，所以跑去玩煉蠱大會，結果用自動化腳本拿了第一名，雖然很大一部分是靠學習對手的 script 來拿分的，但是參與的過程深深的體會到電腦病毒怎麼互相吞噬還有進化能夠改變自己混淆對手，script 最後變得超長一串，過程還蠻有趣的。
不過如果有時遇到高手認真玩起來真的是被殺的不要不要的，我連 reverse shell 都建立不起來
附上 Github 連結 XD 寫的很趕很醜請見諒

https://github.com/danie1Lin/Automation-Script-Malware-Playground-HITCON-2021?fbclid=IwAR3KIhFfjva_CN5Ap46Y8HmP4tKLsJbAhFAFJWdL-h1JschFk3_UXxS4Yl0

Zero-Cost Abstractions in Rust

Daniel Lin — Thu, 25 Nov 2021 16:51:03 +0000

abstraction cost nothing in runtime, only in compile time.

要做到 Zero-Cost Abstractions 其中一個手段就是 generic 的單態化 Monomorphization，Rust 對於 generic 會在編譯時做單態化，什麼意思呢？讓我們直接來看範例

fn add<T: std::ops::Add<Output = T>>(a: T, b: T) -> T {
    a + b
}

fn main() {
    let a = add(1, 2);
    let b = add(1.1, 2.2);

    println!("a: {}, b: {}", a, b);
}

第一個 add 跟第二個 add 其實是不同的函數，讓我們看一下在下面一段天書 -- LLVM IR
可以從 playground 中 compile 的選項調整

裡面可以找到一些蛛絲馬跡，在 LLVM 編譯前變成了兩個函數，看不懂沒關係，我也不懂：P，我們只需要知道 define internal double @_ZN10playground3add17h6a70b05fd089ab8cE(double %a, double %b) unnamed_addr 是給 add::<f64> 的函數實際上的名字
define internal i32 @_ZN10playground3add17hf37e311d0825bf03E(i32 %a, i32 %b) unnamed_addr 是給 add::<i32> 的函數的名字

; playground::add
; Function Attrs: nonlazybind uwtable
define internal double @_ZN10playground3add17h6a70b05fd089ab8cE(double %a, double %b) unnamed_addr #1 !dbg !371 {
start:
    ...
}

; playground::add
; Function Attrs: nonlazybind uwtable
define internal i32 @_ZN10playground3add17hf37e311d0825bf03E(i32 %a, i32 %b) unnamed_addr #1 !dbg !381 {
...
}

在看到 main 函數中 call i32 @XXX 與 call double @XXX 實際上呼叫了不同的 function

; playground::main
; Function Attrs: nonlazybind uwtable
define internal void @_ZN10playground4main17h51a284336407de02E() unnamed_addr #1 !dbg !389 {
start:
  ...
; call playground::add
  %0 = call i32 @_ZN10playground3add17hf37e311d0825bf03E(i32 1, i32 2), !dbg !405
  ...
; call playground::add
  %1 = call double @_ZN10playground3add17h6a70b05fd089ab8cE(double 1.100000e+00, double 2.200000e+00), !dbg !406
  ...

也就是說這個 Add 的 generic 在 compile 時期就將 Add 變成了兩個函數去呼叫，而不是在程式執行的時候才去決定要用什麼函數，不佔用到 runtime 的時間也就達成了 zero-cost abstraction，當然這樣的 trade-off 就是 rust 在 compile 時期會花的時間較多，換取執行時的效能。

不過， rust 編譯時間比較長並非只有這個原因，可以從 playground 的 compile option 這個地方看到 rust compile 要經過非常多的步驟，整個流程 Rust Code -> HIR -> MIR -> LLVM IR -> ASM

而單態化只是 MIR 到 LLVM IR 處理的其中一塊，還有非常多像是：展開 Macro, type check, life-time check 等，都會佔用一些 compile 的時間

另一個手段則是 ZST（Zero Sized Types)，Golang 也是做的到 The Go Playground

func main() {
    type zero struct{}
    fmt.Println(unsafe.Sizeof(zero{}))
}

Zero struct佔用的空間就是 0 ，你可以針對這個自定義的 type 做出不一樣的行為。

而 Rust 則有更多的使用方式，除了 struct 還可以在 generic struct 放入 PhantomData 來將型別一樣的東西，抽象出不同的行為，下面這段程式碼中的 _f size 也是 0 ，執行後可以看到 Expression 只佔了 12

struct Zero();

#[derive(Default)]
struct Expression<T, F> {
    a: T,
    b: T,
    _result: T,
    _f: std::marker::PhantomData<F>,
}

macro_rules! f {
    ( $op:ident($a:tt,$b:tt) ) => {
        Expression::<_, $op> {
            a: $a,
            b: $b,
            ..Default::default()
        }
    };
}

impl<T, F> Expression<T, F>
where
    T: Copy,
{
    fn get_result(&self) -> T {
        self._result
    }
}

impl<T> Expression<i32, T>
where
    T: Call<i32>,
{
    fn execute(&mut self) {
        self._result = T::call(self.a, self.b);
    }
}

trait Call<T> {
    fn call(a: T, b: T) -> T;
}

#[derive(Default)]
struct Add();
impl Call<i32> for Add {
    fn call(a: i32, b: i32) -> i32 {
        a + b
    }
}

#[derive(Default)]
struct Multiply();
impl Call<i32> for Multiply {
    fn call(a: i32, b: i32) -> i32 {
        a * b
    }
}

fn main() {
    println!("{}", std::mem::size_of::<Zero>());
    println!("{}", std::mem::size_of::<Expression<i32, Add>>()); // 3 * size of i32 -> 3 * 4 = 12

    let mut e1 = f!(Add(1, 2));
    e1.execute();
    let mut e2 = f!(Multiply(1, 2));
    e2.execute();
    println!("{} {}", e1.get_result(), e2.get_result());
}

當然不可能所有抽象的手段在 Rust 中都是沒有成本的，先看一下 Golang 最常被使用的抽象手段 interface ，不需要明確寫出實作了哪些 interface 只需要符合接口即可

type Abser interface {
    Abs() float64
}

type MyFloat float64

// 只要函數長的一模一樣就好
func (f MyFloat) Abs() float64 {
    if f < 0 {
        return float64(-f)
    }
    return float64(f)
}

Rust 則需要明確表示實作該接口

struct add();

impl Call<i32> for add {  // 需要明確表示實作 Call<i32> 這個 trait
    fn call(a: i32, b: i32) -> i32 {
        a + b
    }    
}

相較之下 Golang 選擇了的方式，雖然效能較差，但是用法較為靈活，而 Rust 雖然必須明確指出實作接口，但是一樣有提供 Trait Object 做動態時期的分發

引用自rust doc

trait Printable {
    fn stringify(&self) -> String;
}

impl Printable for i32 {
    fn stringify(&self) -> String { self.to_string() }
}

fn print(a: Box<dyn Printable>) {
    println!("{}", a.stringify());
}

fn main() {
    print(Box::new(10) as Box<dyn Printable>);
}

上面可以這樣解讀 10 被當成實作了 Printable 擁有 stringify 的能力的物件，所以在 print function 中可以執行，dyn Printable 意思就是實作 Printable 的物件。

跟 Golang interface 的概念非常接近，其實底層也非常類似 Golang 的 interface 的實作方式，Rust 會用一個 vtable 來儲存物件的資料與使用到的行為，10 在 main 執行時才被傳入，compiler 並不知道是那個 object 執行 stringify 這個 method，只知道 stringify 的函數位置。

但是既然用了這樣的方式實作就代表執行時要先找這個 vtable 才能找到 stringify 的地址，然後才能執行，經過這樣一層層的尋址，自然就無法達成 Zero-Cost Abstractions，但是我們也因此換取了一些程式的彈性，工程上沒有哪一種最好，只有最適合的方式，在 Rust 中你可以比較自由的選擇抽象的方式，但是設計上的選擇多了，自然就會多一些開發的成本，Golang 則是提供一個簡單的方式，有些時候等到你的 application 流量大了，再優化效能也不遲。

String in Rust

Daniel Lin — Wed, 22 Sep 2021 16:46:35 +0000

之前看到一個有趣的圖，在 c 中 string 其實就是 char*，而在 rust 中 string 卻有很多種型別，對寫 Golang 的我來說光是為何要 to_string() 才能 append string 就滿頭問號。

slice, array, vector

講 string 前可以先理解 rust 中 slice, array, vector 的定義
array 為固定長度的序列
[T; N] T 是類型 N 是長度

let s = [1; 5];
println!("{:?}", s);
// [1, 1, 1, 1, 1]

vector 是可以動態增長的序列

let mut s = vec![1];
s.push(2);
assert_eq!(s, &[1, 2]);
assert_eq!(s.len(), 2);
assert_ne!(s.capacity(), 2);

slice 則是對連續空間的 reference，可以是 vector / array 的一部分參考，可以不需要經過複製就可以對 slice 參照的 vector / array 進行操作

常見的 &str 和 String 的差別

&str

let s = "abc";

在編譯時因為 "abc" 長度是固定的所以被認為是靜態的放 stack 上，所以引用時去參照這段位置，所以 s 為 str 這個類別的 reference &str，而 &str 其實是一個 slice 參照 u8 的 array，

String

let s = "abc".to_string();

s 是 String 其實是一個 u8 的 vector，因為是可以動態增長，compiler 不會知道 s 會長多大，所以必須放在 heap 上，可以做下面的操作來改變 String 本身

let mut s = "abc".to_string();
s.push_str("def");

那為何 rust 不把我定義的 "abc" 值當作 [u8] 就好了呢？因為 rust 還同時要確保 &str 中的 [u8] 是合法的 UTF-8 字元，就像大部份語言 char 與 string 的區別，這種 pointer 包含了 type 還有其他規則的 pointer 常被稱為 fat pointer。

可以看出來其實 &str 與 String 類型的差別跟 compiler 將 data 放在 heap 還是 stack 有很大的關係，當你對 &str 使用 to_string 就產生的 memory allocation，所以不需要就不要使用 to_string 增加開銷。

其他意外發現的坑

計算字數

let s = "🗻∈🌏";
let byte = s.as_bytes();

assert_eq!(s.len(), 11);
assert_eq!(s.chars().count(), 3);
assert_eq!(byte.len(), 11);

s.len() 竟然是 11 讓我有點傻眼XD...

Precomposed Characters

除此之外，如果是 precomposed characters 會有很神奇的現象 [1]

println!("{}", "é".chars().count()); // 2
println!("{}", "é".chars().count()); // 1

何會得到不一樣的結果？因為實際上這兩個是不一樣的字程式碼

fn main() {
    assert_eq!("é","é")
} thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `"e\u{301}"`,
 right: `"é"`', src/main.rs:2:5
"""

這讓我理解到數字其實背後也有很多學問，chars count 是數 Unicode Scalar Value，而 "é" 是 e 還有 \u301 這個 Unicode 組成，所以直接算就會是兩個字，那解法就是用 graphemes 這個 method 對應 composited char 的問題

use unicode_segmentation::UnicodeSegmentation; // 1.6.0
fn main() {
    let s = "é";
    println!("{}", s.chars().count()); // 2
    println!("{}", "é".graphemes(true).count()); // 1
}

註 [1]: 感謝 Rust-TW Telegram 上 Lo Weihang 勘誤
Updated at 2021/11/28