CakePHP - неужели не удается загрузить? - PullRequest
0 голосов
/ 11 июня 2010

Может быть, у меня просто медленный день, но из-за жизни я не могу понять, почему это происходит. Я давно не делал CakePHP и пытаюсь использовать версию 1.3, но, похоже, это не работает ...

У меня есть две модели:

area.php

<?php
class Area extends AppModel {
    var $name = 'Area';
    var $useTable = 'OR_AREA';
    var $primaryKey = 'A_ID';

    var $belongsTo = array(
        'Building' => array(
            'className' => 'Building',
            'foreignKey' => 'FK_B_ID',
        ),
        'Facility' => array(
            'className' => 'Facility',
            'foreignKey' => 'FK_F_ID',
        ),
        'System' => array(
            'className' => 'System',
            'foreignKey' => 'FK_S_ID',
        )
    );
}
?>

building.php

<?php
class Building extends AppModel {
    var $name = 'Building';
    var $useTable = 'OR_BLDG';
    var $primaryKey = 'B_ID';

    var $hasMany = array(
        'Area' => array(
            'className' => 'Area',
            'foreignKey' => 'FK_B_ID',
        )                    
    );
}
?>

OR_AREA имеет столбец под названием FK_B_ID, который относится к B_ID.

Если я запускаю что-то вроде:

$this->Building->find('all', array('recursive' => 2));

Я получаю пустые [Area] массивы для всех зданий, даже если в таблице OR_AREA есть много областей, связанных со зданиями. Более того, таблица запросов даже не показывает, что CakePHP пытался найти что-либо, кроме всех записей в OR_BLDG. Тем более удивительно, если я сделаю:

$this->Area->find('all');

Я получаю все Области и массивы [Building] заполняются при необходимости.

Чего мне не хватает?

Edit:

Соответствующие части моей схемы:

CREATE TABLE ORDB_ADMIN.OR_AREA
(
  A_ID            NUMBER(8),
  NAME            VARCHAR2(255 BYTE)            NOT NULL,
  FK_F_ID         NUMBER(8),
  FK_S_ID         NUMBER(8),
  FK_B_ID         NUMBER(8)
)

CREATE TABLE ORDB_ADMIN.OR_BLDG
(
  B_ID           NUMBER(8),
  BLDG           VARCHAR2(90 BYTE)              NOT NULL
)

Я чувствую, что стоит упомянуть, что я использую Oracle , и я нашел билет , который, кажется, описывает, что со мной происходит, но он был закрыт 18 месяцев назад и не было предоставлено никаких реальных сведений о том, в чем заключалась проблема / что было сделано для ее устранения.

Я также нашел комментарий в разделе «hasMany» книги 1.2 CakePHP, который гласит:

Если ваша ассоциация hasMany не возвращает никаких записей, проверьте, совпадают ли типы столбцов первичного ключа и foreignKey. Если один тип int, а другой тип char, вы не получите никаких записей от ассоциации (и никаких предупреждений).

Но, как вы можете видеть выше, ключевые столбцы - это ЧИСЛА на обоих концах (это то, что CakePHP хочет, чтобы они были и для Oracle)

Ответы [ 4 ]

1 голос
/ 14 июня 2010

Наконец выяснил, почему это происходит.Хотя в Oracle CakePHP я определил все столбцы в верхнем регистре, они переносятся в нижнем регистре и не могут найти их, когда вы определяете пользовательские столбцы в верхнем регистре.Поэтому изменение всех моих определений $ primaryKey и foreignKey на строчные решило мою проблему.

Я открыл тикет по этому вопросу, прежде чем выяснить причину, но я не уверен, что есть что-то ещесделано иначе, чем, возможно, сделать запись в Книге, чтобы кто-то не потратил несколько дней на это снова:)

0 голосов
/ 11 июня 2010

Мне кажется, что что-то не так с belogs для ассоциаций в cakephp 1.3.Я думаю, что все будет хорошо, если вы измените свои внешние ключи на area_id и building_id.Взгляните на этот пост.У другого человека была похожая проблема, и это решение сработало для него.

0 голосов
/ 11 июня 2010

При работе с пользовательскими внешними ключами возникают некоторые проблемы.У меня была проблема, похожая на вашу.Сначала я попытался использовать функции динамического связывания, и они работали большую часть времени.

Однако недавно я вернулся и изменил все на xxx_id (cakephp делает много странных вещей с нижними чертами, поэтому xxxx не должен содержать никаких нижних черт.) и все отношения только начали работать идеально.

Поэтому я бы предложил сделать все внешние ключи xxxx_id и посмотреть, решит ли это вашу проблему.

0 голосов
/ 11 июня 2010

Я не уверен, правильно ли это или нет, но у вас есть то, что мне кажется неправильным Модель зоны ForeignKeys ... это так?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...