Re: DB Column Format

[Michael Favia-2]

Nancy Wichmann wrote:
>
> That doesn’t work because the schema is updated by the time the update
> runs. The only thing I can think of now is to rename the old column
> and use “db_column_exists.”
>
Renaming the field sounds like a reasonable alternative to me. Using the
same field in two different fashions even over time can lead to bugs in
third party modules that are difficult to track down because they don't
see actual errors. That said I have since delete the origin of this
thread so i dont know why this was an issue in the first place. Advice
worth price paid. Good luck. -mf

[mark burdett-3]

On Thu, May 14, 2009 at 11:07 AM, Nancy Wichmann <nan_wich@...> wrote:
> Next question: Is there are Drupal or database-independent date formatting
> function that produces a DATETIME value. I know I can use date() with
> something appropriate, but I don’t know how efficient that is.

using PHP functions like gmdate() should always be more efficient,
because these functions (or, date_create() and date_format() in drupal
7) are what format_date() uses anyways. Multiple times in fact.. it's
a rather slow function if you benchmark it.

If you do use format_date() to put dates in the database make sure you
give it a time zone to use, otherwise you will end up with datetimes
in different time zones depending on the current user's configured
time zone.

> Would there be any interest in my submitting a patch for “format_date($time,
> ‘datetime’)?”

If this patch gets committed http://drupal.org/node/325827 then date()
function will also work in the current user's time zone, not the
server-wide time zone, so it wouldn't be useful for inserting dates in
the database or generating date-based URL path components that should
not vary depending on the current user's time zone.  I might be
interested in a helper function that generates dates in the site-wide
default time zone, otherwise developers will be doing this which is
pretty verbose for getting a date: format_date($timestamp, 'custom',
$format, variable_get('date_default_timezone',
date_default_timezone_get()), 'en')

--mark

[Chris Johnson-21]

I think it would be cleaner and clearer to simply find a way to record
which update had completed and check that before running the update.
Checking the column type is always going to be problematic.  Better to
avoid that specific issue altogether.

..chris

On Thu, May 14, 2009 at 2:51 PM, Nancy Wichmann <nan_wich@...> wrote:

> mark Burdett wrote:
>> If you do use format_date() to put dates in the database make sure you
> give it a time zone to use, otherwise you will end up
>> with datetimes in different time zones depending on the current user's
> configured time zone.
>
> Thanks, Mark. In my case, it is the server (hook_cron) that is creating
> these dates, so the timezone doesn't matter.
>
> I just decided to use "date('Y-m-d H:i:s', $now)" where $now is set from the
> PHP 'REQUEST_TIME' value.
>
> Nancy E. Wichmann, PMP
> Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr.
>
> -----Original Message-----
> From: development-bounces@...
> [mailto:development-bounces@...]On Behalf Of mark burdett
> Sent: Thursday, May 14, 2009 2:48 PM
> To: development@...
> Subject: Re: [development] DB Column Format
>
> On Thu, May 14, 2009 at 11:07 AM, Nancy Wichmann <nan_wich@...>
> wrote:
>> Next question: Is there are Drupal or database-independent date formatting
>> function that produces a DATETIME value. I know I can use date() with
>> something appropriate, but I don't know how efficient that is.
>
> using PHP functions like gmdate() should always be more efficient,
> because these functions (or, date_create() and date_format() in drupal
> 7) are what format_date() uses anyways. Multiple times in fact.. it's
> a rather slow function if you benchmark it.
>
> If you do use format_date() to put dates in the database make sure you
> give it a time zone to use, otherwise you will end up with datetimes
> in different time zones depending on the current user's configured
> time zone.
>
>> Would there be any interest in my submitting a patch for
> "format_date($time,
>> 'datetime')?"
>
> If this patch gets committed http://drupal.org/node/325827 then date()
> function will also work in the current user's time zone, not the
> server-wide time zone, so it wouldn't be useful for inserting dates in
> the database or generating date-based URL path components that should
> not vary depending on the current user's time zone.  I might be
> interested in a helper function that generates dates in the site-wide
> default time zone, otherwise developers will be doing this which is
> pretty verbose for getting a date: format_date($timestamp, 'custom',
> $format, variable_get('date_default_timezone',
> date_default_timezone_get()), 'en')
>
> --mark
>
>
> No virus found in this outgoing message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.176 / Virus Database: 270.12.29/2114 - Release Date: 5/14/2009 6:28 AM
>
>

[Steven Jones]

Hi Nancy,

If you have users that run the updates more than once either:

1. There is a bug in Drupal causing updates to be run more than once.
2. Users are selecting the update to be re-run of their own accord.
3. Users are selecting the update to be re-run for some other reason.

So:
1. Is a fairly serious issue.
2. Is their fault.
3. depends who is telling them to do it.

Regards
Steven Jones
ComputerMinds ltd - Perfect Drupal Websites

Phone : [phone]
Mobile : [phone]
http://www.computerminds.co.uk



2009/5/15 Nancy Wichmann <nan_wich@...>:

> Chris Johnson wrote:
>> I think it would be cleaner and clearer to simply find a way to record
>> which update had completed
>
> One would think that checking the "schema_version" in the system table would
> be an easy way to do this. Unfortuantely, update.php is too "smart;" when
> one selects, for example, update 6113 to run, update.php resets the system
> table to 6112 before the hook_update_6113 runs, so checking the table
> doesn't work. Much as I hate to do it, I guess the only way to do this is to
> set a variable.
>
> Nancy E. Wichmann, PMP
> Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr.
>
>
>
> No virus found in this outgoing message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.176 / Virus Database: 270.12.31/2116 - Release Date: 5/15/2009 6:16 AM
>
>

[Earnie]

Quoting Nancy Wichmann <nan_wich@...>:

> I guess the only way to do this is to set a variable.
>

This is the only way for your module to know about its data and what I  
suggest.

--
Earnie
-- http://r-feed.com/           -- http://for-my-kids.com/
-- http://www.4offer.biz/       -- http://give-me-an-offer.com/