Many backported modules may use REQUEST_TIME so we need to safely define it.

CommentFileSizeAuthor
#1 mongodb_define_request_time_1179402.patch262 bytescrea
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

crea’s picture

Status: Active » Needs review
FileSize
262 bytes
fgm’s picture

I think this does not belong in the MongoDB (sub)module(s) : this is a very generic part of D7, and any D7 backport/compatibility like DBTNG, autoload or QueueAPI might want to define it too: testing for defined() does not make us safe against what can happen if another module chooses to define it.

While the proper solution would probably be to have a generic "backport" module which all such inter-version modules should use and rely upon, the safest course until this actually happens (if ever) is probably to have our own module-specific constant.

crea’s picture

Status: Needs review » Needs work

you are right

crea’s picture

It can be also argued that if another module blindly defines the constant without checking its error in that module. We can't control other modules, but we can behave ourselves atleast.
The whole point of keeping using the constant was to minimize code difference between 6 & 7.

fgm’s picture

Maybe someone should create a "backports" project to house all these little things found in all D7 backport modules ?

crea’s picture

Status: Needs work » Needs review

Ok let's gather opinions then

crea’s picture

It's also worth to note that constants should be defined very early in the bootstrap process (regardless of whether you are using specific backported code or not). Moving it to a dedicated backports module would require loading the module code somehow. I think that complicates the whole scenario, making using of if(defined()) checks more appealing.

crea’s picture

Status: Needs review » Closed (won't fix)

Ok, I think it's much easier just to use $_SERVER['REQUEST_TIME'] than to waste time in debates.
I also think that having separate code bases is inevitable http://drupal.org/node/1089504#comment-4655694 so closing this.