Data types

The primitive types

Here is a list of primitive data types supported in EZPDO.

  • bool
  • int(m)
  • decimal(m,d)
  • float(m)
  • char(m)
  • clob(m)
  • blob(m)
  • date
  • time
  • datetime

bool, int, float

Boolean, int, and float are the same as those defined in PHP and are simply mapped to the corresponding default database column types.

char, clob, blob

The types, char/clob/blob, are for PHP strings, of which char is for relatively short text string, clob for long strings, and blob for long binary strings. You can use parameter “(m)” to specify the maximum length for the char/clob/blob column. By default, m is 512.

data, time and datetime

For simplicity, the data, time, and datatime types are all simply modeled as Unix timestamp (the number of seconds since the Unix Epoch (January 1 1970 00:00:00 GMT) and are mapped to int(16) in database.

Summary of primitive types

The following table summarizes the supported data types.

type alias(es) parameters comments
bool boolean, bit Mapped as 1-byte integer
int(m) integer(m) m: Number of digits Maped as m-type signed integer
decimal(m,d) m: total digits, d: digits after decimal point
float(m) real(m) m: Precision Synonym for ANSI real
char(m) m: Number of bytes Mapped as VARCHAR
clob(m) text(m) m: Number of bytes Long text string
blob(m) m: Number of bytes Long binary string
date Modeled as unix time, int(16)
time Modeled as unix time, int(16)
datetime Modeled as unix time, int(16)

Keep in mind that if parameter (m) is not specified, it is default to the default value of the underlying database column type.

Too few types?

As you may have noticed, the types listed above are far fewer than the column types any specific database supports. Take the popular MySQL for example, version 5 supports more than 20 column types.

We choose to use as few data types as possible for simplicity so to ease the ORM specification task for the user. EZPDO makes the decision on how to map them to the column types of a specific database.

Beyond primitive types

So we have addressed the primitive data types. What about the complex ones? Objects and arrays? For those non-primitive data types, they have everything to do with object relationships that we address in object relationships.

12 user comments

  1. Juan Carlos Gonzalez on October 14th, 2005:

    What happened with the ENUM data type? It’s very very useful!

  2. ezpdo4php on October 15th, 2005:

    Juan, good question. The reason that we ruled out ENUM was for db compatibility as we did not see ENUM as a universally defined type in dbs we have encountered.

  3. Juan Carlos Gonzalez on October 27th, 2005:

    Too bad! and is there any way to figure out an ENUM field using ezpdo? because I want to render out forms automatically. Thank you in advance!

  4. ezpdo4php on October 28th, 2005:

    sure! i think it should be very doable with the current version of ezpdo. you may define an enum class, say,

    class myTag {
    // @orm char(24)
    public $name;
    }

    you will need to insert some values initially. for example,

    // $m is the ezpdo manager
    $m = epManager::instance();

    $t1 = $m->create(’myTag’);
    $t1->name = ‘tag1′;
    $t1->commit();

    $t2 = $m->create(’myTag’);
    $t2->name = ‘tag2′;
    $t2->commit();

    // … you may add more …

    now keep in mind that unlike static enums, your enum class myTag is really dynamic, meaning that you can change it over time.

    now when rendering your form, you can pull out the enum values like this,

    $tags = $m->get(’myTag’);
    foreach($tags as $tag) {
    // do whatever you want with each tag
    // … you code here …
    }

    let me know if this works out for you. -oak

  5. Marc on November 8th, 2005:

    I think varchar and long is pretty much a necessity for any database… this has potential though, I’ll keep an eye on it.

  6. Simonbun on June 6th, 2006:

    How come varchar is not supported?
    Please excuse my negativism but:

    Lets say i have MySQL database with a column wich holds up to 100 characters. This column varies in actual submitted content. Lets say that, on average, 50 chars out of 100 get used.

    A char(100) has a footprint of 100 Bytes.
    A varchar(100) has a footprint of (# of chars actually used)+1 Bytes.

    Now lets assume my table holds 10.000 records.
    The char(100) column would use 100 Bytes * 10.000 records = 1.000.000 Bytes = 976,5625 KiloByte.
    The varchar(100) column would use (50 + 1) * 10.000 records = 510.000 Bytes = 498,046875 KiloByte.

    Thats almost half its size. And this is just one column in one table in one database.

  7. ezpdo4php on June 6th, 2006:

    simonbun, thansk for the question. the data type, char, is internally mapped to varchar. see this bug report.

  8. Simonbun on June 7th, 2006:

    Thats good news, then ezpdo will be used for our upcomming projects.

  9. staalanden on January 23rd, 2007:

    How do i tell ezpdo to md5 encrypt a column?

  10. odpze on January 23rd, 2007:

    A column normally maps to a variable in an object. So to encrypt, do something like this:
    $o->var = md5($o->var);

  11. staalanden on January 23rd, 2007:

    Thank you, but i would like to do it in my UML editor as part of the type(like using password in mysql) in order not to overwrite when editing the model.

    I am using xmi2php to transform my model into @orm compliant classes.

    Isn’t it possible to tell ezpdo to store variables encrypted

  12. ezpdo4php on January 23rd, 2007:

    not sure how you would pass that info from uml tool to class @orm tags unless you extend the tags and parsing. maybe you can accomplish this through event listners - apply md5() when object is saved (firs time persisted).

Post your comments

XHTML: tags you can use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

Couldn't find your convert utility. Check that you have ImageMagick installed.