Codegenta

is code generation tool designed to work along side with rustorm to eagerly create Rust structs based on the database tables meta data information.

Why?

There are a lot of ways to express database tables using a multitude of libraries around the ecosystem. Arguably the most prevalent way(without too much of overhead/learning curve) is by using database GUI tools such as PgAdmin.

The way to do these is, you create database tables, you then create the corresponding struct in your code. This is an iterative process wherein you will add/remove/edit the table definition as you develop you application. Often times, it's easy to make inconsistencies.

Example

Terminology and tables

• Product table holds the list of products in our example app.
• Users is a user table (plural due to user being a reserved keyword in most databases).
• Category - categories of products, items etc.
• Photos - product/item listing would be much more pleasing if it has pictures.
• Reviews - a review of users for a certain product.
• ProductAvailability - determines office time of the seller when a certain product is availability. Anouncement of product before it is available. This is much more applicable to services.

Code to look at

• Take a look at examples/generatemodelcode.rs. This generates a source code that is comparible to what you could have written as a model code of your project.

• The source code generated is located at ./gen folder

```sql

CREATE TABLE bazaar.product ( productid uuid NOT NULL DEFAULT uuidgeneratev4(), name character varying, description character varying, price numeric, currencyid uuid, unit character varying, barcode character varying, ownerid uuid, currencyid uuid, CONSTRAINT productpkey PRIMARY KEY (productid), CONSTRAINT productcurrencyidfkey FOREIGN KEY (currencyid) REFERENCES payment.currency (currencyid) MATCH SIMPLE ON UPDATE CASCADE ON DELETE RESTRICT DEFERRABLE INITIALLY DEFERRED, CONSTRAINT productuseridfkey FOREIGN KEY (ownerid) REFERENCES bazaar.users (userid) MATCH SIMPLE ON UPDATE CASCADE ON DELETE RESTRICT DEFERRABLE INITIALLY DEFERRED )

```

The generated model code

```rust

[derive(RustcDecodable, RustcEncodable)]

[derive(Debug, Clone)]

pub struct Product { pub productid:Uuid, pub name:Option, pub description:Option, pub barcode:Option, pub currencyid:Option, pub owner_id:Option, pub price:Option, pub unit:Option,

pub owner: Option<Users>,
pub currency: Option<Currency>,
pub availability: Option<Box<ProductAvailability>>,
pub category: Vec<Category>,
pub photo: Vec<Photo>,
pub review: Vec<Review>,

}

```

• pub product_id:Uuid, marked the column product as NOT NULL therefore it will always have value.

• pub name:Option<String> is an option since, we did not specify that this non nullable. Same as descrption and etc.

• pub owner: Option<Users>, base on the foreign key constraint, codegenta is smart enough to recognize that a product has an owner based on the owner_id which references Users table. Codegenta then add an optional field owner:Option, which you can then later use in you app to hold an additional info about the seller of a certain product.

• pub currency: Option<Currency>, currency_id specifies which currency a product is using. You can put the used currency in the product in your controller code to include a more detailed information about the currency used without having make additional container structs.

More advance features

Take a look at the table schema used in these examples provided by the project.

• pub category: Vec<Category>, - the codegenta is also smart to recognize that product table is referred by Category table with a linker table product_category, which provides a 1:M relationship between product and category, since products can have multiple categories

• pub photo: Vec<Photo>,

• pub review: Vec<Review>,

Same applies for Photo, with linker table product_photo and Review table with linker product_review

• pub availability: Option<Box<ProductAvailability>>, - product availability is another unique feature of codegenta that determines that ProductAvailability table is just an extension table of product and has a 1:1 relationship, since each product can only have 1 product availability.

A complex query when using codegenta

link ```rust

extern crate rustorm; extern crate uuid; extern crate chrono; extern crate rustc_serialize;

use rustorm::query::Query; use rustorm::query::{Filter,Equality}; use rustorm::dao::{Dao,IsDao}; use gen::bazaar::Product; use gen::bazaar::product; use gen::bazaar::Photo; use gen::bazaar::photo; use gen::bazaar::Review; use gen::bazaar::review; use gen::bazaar::Category; use gen::bazaar::category; use gen::bazaar::productcategory; use gen::bazaar::ProductCategory; use gen::bazaar::productphoto; use gen::bazaar::ProductPhoto; use gen::bazaar::ProductAvailability; use gen::bazaar::product_availability;

use rustorm::table::IsTable; use rustorm::pool::ManagedPool;

mod gen;

fn main(){ let mut pool = ManagedPool::init("postgres://postgres:p0stgr3s@localhost/bazaar_v6",1); let db = pool.connect().unwrap();

let mut query = Query::select_all();

query.from(&Product::table())
    .left_join(&ProductCategory::table(),
        product_category::product_id, product::product_id)
     .left_join(&Category::table(),
        category::category_id, product_category::category_id)
    .left_join(&ProductPhoto::table(),
        product::product_id, product_photo::product_id)
    .left_join(&Photo::table(), 
        product_photo::photo_id, photo::photo_id)
    .filter(product::name, Equality::EQ, &"GTX660 Ti videocard")
    .filter(category::name, Equality::EQ, &"Electronic")
    .group_by(vec![category::name])
    .having("count(*)", Equality::GT, &1)
    .asc(product::name)
    .desc(product::created)
    ;
let frag = query.build(db.as_ref());

let expected = "

SELECT * FROM bazaar.product LEFT OUTER JOIN bazaar.productcategory ON productcategory.productid = product.productid LEFT OUTER JOIN bazaar.category ON category.categoryid = productcategory.categoryid LEFT OUTER JOIN bazaar.productphoto ON product.productid = productphoto.productid LEFT OUTER JOIN bazaar.photo ON productphoto.photoid = photo.photoid WHERE product.name = $1 AND category.name = $2 GROUP BY category.name HAVING count(*) > $3 ORDER BY product.name ASC, product.created DESC ".to_string(); println!("actual: {{{}}} [{}]", frag.sql, frag.sql.len()); println!("expected: {{{}}} [{}]", expected, expected.len()); assert!(frag.sql.trim() == expected.trim()); } ```

Look at those pretty generated SQL's

Roadmap

• Support for the other way around?
• The user writes the model and create a corresponding table in the database