Server-side and client-side ORM

  1. mschwartz
    Allow me to present a snippet of Javascript code. It's relevant for both client and server side programming.

      name: 'Users',
      fields: [
        { name: 'userid', type: 'int', defaultValue: 0, attr: 'auto_increment', grid: true },
        { name: 'username', type: 'varchar', size: 100, defaultValue: 'Guest', validator: Validator.username, editor: 'textfield', grid: true, label: 'Username' },
        { name: 'password', type: 'varchar', size: 64, defaultValue: '', validator: Validator.password, editor: 'password', grid: false, clean: true, label: 'Password' }
        { name: 'email', type: 'varchar', size: 100, defaultValue: '[email protected]', validator:, editor: 'textfield', grid: true, label: 'Email' },
        { name: 'ipAddress', type: 'varchar', size: 15, defaultValue: '', validator: Validator.ipAddress, editor: 'textfield', grid: false, clean: true }
      primary_key: 'userid',
      indexes: [
    Schema is a singleton, and there is a version for the server and another for the client.

    The server version provides a method create(name) that generates MySQL "create table" statement for the named schema. It also provides get() and put() methods that fetch (and possibly cache) records from the database. The cache would be indexed by primary_key and indexes. There are other obvious methods, like list() which returns something like:
      count: number_of_records,
      records: [ array of records ]
    (suitable for json encode for grid stores)

    The client Schema singleton provides a method createRecord(name) that returns an Ext.Record. It provides a createColumns(name) that returns a config for grid columns. It provides a createForm(name, record) that returns an array of form field configs, using record (if provided) as the field values otherwise it uses the defaultValue of the schema.

    Note that enough information is provided in the schema to generate forms with validation, grids with headers, Records, and so on. These cannot be derived by looking at pure SQL or 'describe table' query output.

    The Validator class is shared between client and server, so you can validate a form on the client side, then validate it on the server side before comitting to the database.

    The clean attribute tells the server not to send this field as part of any Json response to the client. Don't want encrypted passwords or peoples' IP addresses sent over the wire.

    To get even fancier, the Schema class could store the last known schema (json encoded) in some administrative table in the database. An additional server-side method could do the equivalent of diff (diff3, actually) on the current schema at Schema.reg() time with the one in the database. It would execute the SQL "alter table" statements necessary to make the actual table in the database match the immediately registered one.

    Obviously all this is a rough sketch of the idea and there's a lot more expansion on this concept to be done. For example, the schema definitions could provide constructor and other methods to operate on the records. For true CRUD, there needs to be a remove() method. On the server-side, would automatically process the POST variables and create/update the record in the database.

  2. Frank
    Pure SQL is good enough. besides, NoSQL is hit now...
  3. mschwartz
    NoSQL has some issues, particularly bloat of data size. If you have a record that looks like { username: 'xxx', firstname: 'yyy' ... }, then 'username' and 'firstname' take space in memory and on disk (times the number of records!).

    And pure SQL is not enough. it doesn't allow you to specify that a column should be displayed in an ExtJS grid. That's the whole point of my post
Results 1 to 3 of 3