More PHP ORM disappointment
2012-01-31 12:39 pm ∴ PHP,Rant ∴ Tags: , , ∴ by matt -

OK, so I know I’ve been beaten this horse to a pulp. But today it reared its ugly head again.

The ORM in this case is phpActiveRecord. I had used this in other projects and had a generally positive experience, so I thought it would be a decent fit for this quick little user registration database I had to set up.

Of course, I had neglected to check whether or not phpActiveRecord worked with PostgreSQL. Silly me, when I looked at this page and saw ‘pgsql’ in a DSN, and when I read that PDO is used for the backend — which provides a decent API for the library to use — I assumed that I would be safe.

In short terms, no. In longer terms, fuck no.

There’s an error, apparently in all versions that I could find, in the pgsql adapter. I guess there were some attempts to fix it, but it remains uncommitted to the main branch, despite being a year old.

So good-bye to phpActiveRecord. It was fun, that one time when I used you and you worked correctly. You can now join the wall of shame with lack of PostgresQL support along with WordPress and Drupal. (Yes, I know Drupal core has at least partial support, but modules may not necessarily support pgsql — which could have been avoided with a decent ORM).

The saga continues… sigh…

Completely unfair, totally biased review of PHP ORM libraries
2009-05-07 4:37 pm ∴ Rant,Thoughts ∴ Tags: , , , ∴ by matt -

This has been on my mind for a long, long time. Having been spoiled with SQLAlchemy and Elixir, I am tortured with sub-par ORM libraries while at work. Granted I did get to use SA for an internal project, but the majority of the things I do involves PHP.

I’ve been stuck with it for years. It is the language of choice for people who run servers and hate web developers. So yeah, 5 years of PHP and MySQL …and using so many different libs for database abstraction has given me some room to shoot my mouth off.

Anyway, this is going to be a long post and not for the faint of heart.  I’m going to start off at the beginning…

(more…)

Fun with PHP dates
2009-02-05 11:53 am ∴ Programming,Thoughts ∴ Tags: , , , ∴ by matt -

So in a recent project, I had to handle some formatted dates. Piece of cake right? Date handling in PHP is a snap with date() and strtotime(). In fact, I’ve often said that the date functions are the best part of PHP, so I’ll have this knocked out in no time.

Well, maybe not.

I’m handling credit card expiration dates specifically in this case. Usually, the user is given a choice of months and years in a drop-down list. “That’s too annoying,” I thought, “It’s much faster to just type it in and let PHP handle the date formatting.” The expected input format is mm/yy so, of course I proceed with something like this for storage:

date("m/Y", strtotime($ccexpr));

Done and done! Hmm…until I tested it.

Turns out that strtotime() doesn’t like the format mm/yy. So maybe if I enter it as mm/yyyy it’ll be ok. No, not ok there either. “That’s kind of odd,” I thought. So I head to the function’s page to see if there are any user comments on it and I see this:

strtotime returns time() for any string that begins with “eat” (case insensitive)

Hrm? What sense does that make? It could be an abbreviation, but what does EAT stand for? Well, I’m getting off point by now, so I set up some tests to see what I could figure out with strtotime():

strtotime():
2/8/2010 => 02/2010
2.8.2010 => 08/2010
2010-2-8 => 02/2010
2/8/10 => 02/2010
2.8.10 => 02/2009
10-2-8 => 02/2010
2/10 => 02/2009
2/2010 => false
2010-02 => 02/2010

Weird huh? 2/8/10 gives the correct year, but 2.8.10 doesn’t? 2/10 gives the wrong year (because it’s assuming the date given is 2/10/current_year), but 2/2010 fails? Yet, 2010-02 works. I’m kinda baffled by this, but I’m sure there are some eccentricities to this function since it handles stuff like “tomorrow +20 years.”

So, since I’m asking for a specific format, I decide to switch to strptime(). As with all PHP functions I seldom use, I check to make sure it’s available in the version I’m using. Since 5.1? Ok, whew! Wait…really? This is a pretty basic date function that’s provided in the C run-time. Why did it take so long to get in to PHP? Ok that’s beside the point — but I look a little down the page and see:

Note: This function is not implemented on Windows platforms.

What? Why? It’s like I’m in bizarro world or something. Am I crazy?

Ok — it still doesn’t matter, there are still things here that need to be done, I just can’t test it on my machine at work. No biggie. So I check strftime() to see about the formatting codes. Hmm. Wait a second…again…  strftime() has been available since PHP 4? Why it — what — not — both — ? Arghhh!

I must be crazy. I must be. If I’m not, PHP will surely drive me there.