alex_oblog

ну что за уродство? mysql будь он не ладен... и еще myisam! ну вообще ни в какие ворота, но в этом проекте -вариантов нет...
а надо сподобится изобразить транзакцию, т.е. придется залочить таблицу.. вообщем-то, по сути всего одну..
а именно:надо выполнить нехитрую выборку из этой таблицы с подзапросом из нее же.. т.е. использую алиасы этой таблицы.. а потом 2 простеньких апдейта в этой же таблице.. собственно тут мне алиасы ни к чему..
lock tables - настолько тупой, что чтобы сие выполнилось приходится прописать в нем и таблицу с обоими алиасами и без них... т.е.:

блин, ну мы все же знаем что myisam не транзакционный, т.е. указывание алиасов не может указать что под этим алиасом произойдет запрос на блокировку (acquire locks), а если обратиться через иной - нет. так нафига такой уродливый синтаксис?
ну и совсем полное непонимание вызывает гадостное сообщение - что дескать таблица Таб1 не была залочена, если сделать к ней обращение между LOCK TABLES - UNLOCK TABLES, не указав оную.. т.е. пока я не прописал таблицу без алиаса - я не смог выполнить свои апдейты... факушка ануксунамун!!! это же все время одна и та же таблица..

разумеется, что для несчастных, которые вынуждены были изображать транзакции на myisam - я америку не открыл.. они уже все давно это прочитали в мане. а я бы хотел этого так никогда и не узнать :(

Таки, менее 70-ти строк хранимка, которая позволяет изменить количестово доступных мест в шайтан-арбе, корректно обработав такие мелочи как уже забронированные места на каждой из промежуточных станций. Особено приятно, что потребовалось всего полчасика вдумчивого дебага. я довольный.

Маленький спотыкач для желающих использовать полиморфные типы, такие как anyarray. Допустим, есть функция:

CREATE OR REPLACE FUNCTION array_func(anyarray, anyarray) RETURNS anyarray as $$
begin
	if $1 is null then
		return $2;
	end if;
	....
end;
$$ language plpgsql;

При вызове:

select array_intersection(null, null);

будет кака типа: ERROR: could not determine polymorphic type because input has type "unknown"
что вполне объяснимо. надо так:

select array_intersection(null, null::integer[]);

т.е. если буквально: "ПЕЙТЕ МОРКОВНЫЙ СОК" (с)

Вообще-то штатными срадствами такой апгрейд не предусмотрен.
Но методом научного тыка, было установалено, что если изменить ссылки на описания пакетов обновлений с этого:
http://dlc.sun.com.edgesuite.net/netbeans/updates/6.8/uc/beta/stable/catalog.xml.gz
на это:
http://dlc.sun.com.edgesuite.net/netbeans/updates/6.8/uc/final/stable/catalog.xml.gz

то вполне реально :) ну разумеется, если юзаются сторонние или бета-версии модулей - то повторить движение по-анологии.
при инсталяции раздалась ругань и отвалилась куча модулей, но последующий апдейт доставил отсутсвующие модули, и потом вручную активировал все то, что отвалилось. Кроме JavaFX, но он мне без надобности, я его деинсталировал. Думаю, что можно просто заново бесприпятственно его поставить.

UPD: вообщем, практика показала, что только ради спортивного интереса - это возможно, но в реале это изврат:
- скачивается столько же МБ сколько и при установке с нуля
- отвалилась система подсказок/документации php - танцевать с бубном и чинить - было в лом
- чето там еще, не помню.

скачал оригинальный 6.8 и установил :)

Забавная функция, в предыдущих версиях работала криво - не все js-библиотеки соглашались переваривать то, что она предлагала. Ну вот например, есть у меня самый обычный массив, скажем созданный функцией range(), если у меня ключи целочисленные и упорядочены от наименьшего к большему - то json_encode() вернет вполне себе нормальный js-array, но если вдруг порядок ключей изменить или удалить один из них - получится объект. В php 5.3 добавили опции, среди прочих JSON_FORCE_OBJECT, так как функция, иногда, для пущей важности, генерирует смешанное содержимое. А вот JSON_FORCE_ARRAY - не догадались. Собственно, если вы еще кипятите используете ее, и вам важно получать в результате именно массив, то придется проконтралировать сортировку и наличие всех ключей, например, сгодится array_slice().

Чего-то я сначала загнался - генерировал случайный индекс, и ансетил элемент, до тех пор пока не убью нужно количество.. Детсад какой-то.. Но уже опустило :)

   $arr = range(0, $max);
   shuffle($arr);
   $arr = array_slice($arr, 0, $n, true);
   ksort($arr);

факиншит.. слишком много кофе :)

Даты.. даты.. врменные промежутки, вычисления... факиншит...опять них не работает! а я так надеялся, что появится нормальный класс DateTime который сможет решить мои проблемы.. Впервые глобально озаботился проблемой еще тут . Но решить ее оказалось лень - каку написал и забил. А вот теперь другой проект, тут надо по-любому решать!

Вообщем устанавливаем врменную зону Europe/Mosсow , вспоминаем когда был переход на зимнее время в прошлом году 25.10.2009 в 03:00 сделали 02:00 . И начинаем испытывать класс DateTime .

<?php
/**
 * @author alexob
 */
require_once 'PHPUnit/Framework.php';

class PHPComplianceTest extends PHPUnit_Framework_TestCase{

    public function testVersion(){
        $this->assertTrue(defined('PHP_VERSION_ID'));
        $this->assertTrue(PHP_VERSION_ID >= 50300);
    }


    public function testDateTimeClass(){
        date_default_timezone_set('Europe/Moscow');

        $dt = new DateTime('2009-10-25 03:00:00+03');
        $this->assertTrue(
           (new DateTime('2009-10-25 02:00:00+04'))   //говорит баго: '2009-10-25 01:00:00+03'
            ==  
            $dt->sub(new DateInterval("PT2H"))
         );

        $dt = new DateTime('2009-10-25 03:00:00+03');
        $this->assertTrue( 
            (new DateTime('2009-10-25 02:00:00+04'))  //говорит баго: '2009-10-25 01:00:00+03'
            ==  
            $dt->modify("-2 hours")
         );
        
        $dx = new DateTime('2009-10-25 03:00:00+03');
        $dt = DateTime::createFromFormat('U', $dx->format('U'));
        $dt->sub(new DateInterval("PT2H"));
        $dt->setTimezone(new DateTimeZone('Europe/Moscow'));
        $this->assertTrue( (new DateTime('2009-10-25 02:00:00+04')) ==  $dt);  //на удивление, правильно

        $dt = new DateTime('2009-10-25 01:00:00+04');
        $this->assertTrue( (new DateTime('2009-10-25 02:00:00+03')) ==  $dt->add(new DateInterval("PT2H"))); //верно

        $dt = new DateTime('2009-10-25 01:00:00+04');
        $this->assertTrue( (new DateTime('2009-10-25 02:00:00+03')) ==  $dt->modify("+2 hours"));            //верно

    }
    
}

Дальше уже тесты писать стало бессмыслено - оно на половину рабочее (только "вперед").
Все проблемы вертятся вокруг DST. Многим оно (DST) до одного места, у многих вообще одна временная зона (или они о том не задумываются/не знают) и они вполне юзают обычные unix timestamp (чаще даже не UTC, а локальное время) и с чистой совестью для получения след. дня делают += 24 * 3600 .

Особо ушлые (на гуглил такой маневр :) ), поступают вообще интересно :) :

<?php
  $ONE_DAY = 90000;   // can't use 86400 because some days have one hour more or less
  for ( $each_timestamp = $start_time ; $each_timestamp <= $end_time ; $each_timestamp +=  $ONE_DAY) {

    /*  force midnight to compensate for daylight saving time  */
    $this_timestamp_array = getdate( $each_timestamp );
    $each_timestamp = mktime ( 0 , 0 , 0 , $this_timestamp_array[mon] , $this_timestamp_array[mday] , $this_timestamp_array[year] );

     // do some stuff...
  }
?>

Вообще-то функция mktime() может выполнять временнУю арифметику в рамках желаний большинства.. но не моих.

Когда я не смог в течении нескольких часов получить метку времени "полночь" в сутках в которых происходит смена на летне/зимнее время - я забил на DateTime() и успокоился. Переписал этот unit-test наоборот, подставив "ошибки" вместо верных ответов и буду ждать.. рано или поздно это будет исправлено, вот тогда сей тест и завалится, значит пора будет убирать "костыли" и юзать сей мега класс DateTime :(

А в качестве костылей пока использую функции которые все вычисляют с помощью pgsql - там все как в аптеке.

Мож я туплю? может у меня ошибки? хде?