kdyby / doctrine Goto Github PK

defining that App\Entities is in %appDir%/models from config and in %appDir%/../libs/App from provider must not colide.

Ref #71

In the latest version of nette the class PhpGenerator is in namespace Nette\Utils\PhpGenerator, so it throw out an error:

"Declaration of Kdyby\Doctrine\DI\OrmExtension::afterCompile() should be compatible with Nette\Config\CompilerExtension::afterCompile(Nette\Utils\PhpGenerator\ClassType $class)"

Is there any good reason not to?

When the parameter is bound with custom type DATE, it's rendered incorrectly as DATETIME.

The query looks like:

column = '2013-08-12 15:03:52'

whereas it should look like:

column = '2013-08-12'

I guess Type::DATETIMETZ is also not distinguished.

Problematic line:

Always call $cache->clean(array(Cache::ALL)) before these commands, so they generate fresh data

• orm:schema-tool
• orm:validate-schema
• orm:generate-proxies
• orm:info

Named and Identified entity definitions are different. Please show us the right way!

Wrap both listeners with necessary code to make them work with Kdyby/Events.

ResolveTargetEntityListener

rtel:
   <class|interface>: <class> # simple
   <class|interface>: # extended with mapping
      class: <class>
      mapping:
         a: b

It might be useful to have extension interface for RTEL.

DebugUnitOfWorkListener

Probably would be best to have enable option for each event (performance)
Attach to debug panel?

Teď je natvrdo zadrátovaný Kdyby\Events\Manager, to celé jen kvůli jednomu tagu, který by se dal snadno přenést do konfigurace.

Důvody pro změnu na volitelný:

• Kdyby\Doctrine funguje i s EM z Doctrine
• Pokud si vystačím s obecnějším rozhraním, nedělám závislost na specializovaném(!) potomkovi (princip generalizace/specializace je základ OOP).
• Nefunguje Gedmo, které si ověřuje listenery a zabugovaný KEM vrací nesmysly.
• Každá nástavba představuje potenciální zdroj chyb a chtěl bych mít volbu přínosy/zápory: dneska například malý dependency hell, kdy se mi kvůli závislosti K\D na K\E degradoval Composer Nette z 2.1 na 2.0. Musel jsem to řešit přidáním K\E do závislostí mého projektu, ač to nepoužívám (vynucená prasárna).

Čauky,
mám problém s tímto commitem:

a142375

Díky úpravě v metodě flush se přestali promítat nově persistované entity do databáze, resp. celé vše proběhne korektně, ale změna se neprovede a je to způsobeno onou podmínkou, jelikož "getIdentityMap" vrací pouze poslední relaci na entitě, například pokud vytvořít entitu Foo, která má závislost na Bar, a zavolám na ní save, tak metoda v identityMap je pouze entita Bar, a tudíž se flush neprovede.

i am catching DuplicateEntryException in various places in my code. Suddenly kdyby stopped throwing this exception and DbalException is being thrown instead.

the problem lies in Kdyby\Doctrine\Connection lines 207 and below.
the $info = $pe->errorInfo; is NULL so the condition on line 216 is skipped completely

i have no idea how this could happen.

but wouldn't it be more reliable to use $pe->sqlState as exception discriminator?

• Element::fromString by měl být lazy

It would be nice if OrmExtension::register($configurator) could register extensions which are dependencies for this extension. It means Kdyby\Event and Kdyby\Console.

and dumps what was happening and off switch uowDebugger: off

This commit doctrine/orm@b0513a7 causes Strict standards error.

dbal:reserved-words real time saver!
dbal:run-sql quite useful?
orm:ensure-production-settings might be useful?

Hi,

when I haven't indexed folder with proxy classes, doctrine ignore it and correctly work (I don't understand why?).

I met with it, when I serialized entity - serialization was correct, and unserialized too in same request, but when I transfer it through request (session) - unserialized crash because proxy class not found.

Doctrine would be check if proxy classes can be loaded. I think that can be useful, when Kdyby self call "orm:generate-proxies" and check class_exists for generated classes too on development mode. This solution fix problem when somebody forgets generate all proxies before deployment too (own experinces).

Ahoj,

kdyz jsem stahl posledni Nette a Kdyby/Doctrine, vyskakuje na me tato hlaska. Rekl bych, ze se v nektere z poslednich verzi Nette zmenily jmenne prostory nekterych trid

    /** @var array */
    public $renamed = array(
        'Nette\Config\Configurator' => 'Nette\Configurator',
        'Nette\Config\CompilerExtension' => 'Nette\DI\CompilerExtension',
        'Nette\Http\User' => 'Nette\Security\User',
        'Nette\Templating\DefaultHelpers' => 'Nette\Templating\Helpers',
        'Nette\Latte\ParseException' => 'Nette\Latte\CompileException',
        'Nette\Utils\PhpGenerator\ClassType' => 'Nette\PhpGenerator\ClassType',
        'Nette\Utils\PhpGenerator\Helpers' => 'Nette\PhpGenerator\Helpers',
        'Nette\Utils\PhpGenerator\Method' => 'Nette\PhpGenerator\Method',
        'Nette\Utils\PhpGenerator\Parameter' => 'Nette\PhpGenerator\Parameter',
        'Nette\Utils\PhpGenerator\PhpLiteral' => 'Nette\PhpGenerator\PhpLiteral',
        'Nette\Utils\PhpGenerator\Property' => 'Nette\PhpGenerator\Property',
    );

Current behaviour is a bit confusing.

Configuration of entity mapping is ambiguous because it can be added globally via provider from extensions or per instance via configuration to EntityManager. But the global from extensions overrides the specific from configuration.

Hi Filip,

I found some error maybe .. I have QueryObject:

class FooQuery extends Kdyby\Doctrine\QueryObject
{

    /**
     * @param Kdyby\Persistence\Queryable $dao
     * @return Doctrine\ORM\Query|Doctrine\ORM\QueryBuilder
     */
    protected function doCreateQuery(Kdyby\Persistence\Queryable $dao)
    {
        return $dao->createQueryBuilder()
                    ->where("bar = :param")
                    ->setParameter("param", "value");
    }

}

And when I call it trough DAO:

$this->em->getDao("FooEntity")->fetch(new FooQuery());

I get error "[FooQuery] instance of Kdyby\Doctrine\QueryBuilder", but when I look at code in QueryObject.php:70, in condition you check instanceof Doctrine\ORM\Query, but in message you have "... instanceof Doctrine\ORM\Query or instanceof Kdyby\Doctrine\QueryBuilder ...", but in condition "Kdyby\Doctrine\QueryBuilder" miss and this object doesn't extends Doctrine\ORM\Query.

Thanks :)

nette/di@7e4236c

All of the "unified README files" have the same mistake in Learn word ( Lear more in the documentation).

• bridge for data mapping entity <-> form
• integrate Symfony/Validator
• validation violations map to form fields as error messages

This behavior is not implemented in Doctrine. I think it could enable richer modularity. I reserve the right to be dead wrong.

Using RTEL relations can be declared using interfaces without knowing class of implementation.

Application of this approach reaches dead end when using entity.dao factory or EntityManager::getRepository or alias getDao in code. Basically reaching for repository using interface is not supported. Reasoning: Whole extensions and models can get away without knowing class name of actual implementation, using interface should allow more room.

Roadmap

• Implement RTEL part of #40 (extension interface and configuration)
• Hashmap will be extracted from RTEL configuration as [ interface => configuration ]
  (not including mapping information)
• Add last parameter to EM constructor/create with hashmap.
• Override getClassMetadata to check hashmap before checking class existence

Note: Solution should not be limited to only one interface per class.

In new repository as new package, preferably.

Interface Kdyby\Persistence\Queryable has method createNativeQuery which returns Doctrine\ORM\NativeQuery (extends Doctrine\ORM\AbstractQuery). However class Kdyby\Doctrine\QueryObject cannot work with the result of this method. It works only with

• Doctrine\ORM\Query (extends Doctrine\ORM\AbstractQuery),
• Kdyby\Doctrine\QueryBuilder and
• Kdyby\Doctrine\DqlSelection.

I use Kdyby\Doctrine\QueryObject to remove complicated queries from classes where Kdyby\Persistence\Queryable is used. But when I need to use NativeQuery then I must write my own abstraction or left complicated query in class where Kdyby\Persistence\Queryable is used.

Čauky,

využívám architektury vlastních doménových dotazů, viz článek http://filip-prochazka.com/blog/doctrine-a-service-vrstva-aneb-takto-mi-to-dava-smysl

Poté když předám onen QueryObject metodě fetch z DAO, tak jsem narazil na problém s ResultPaginator.

Konkrétně u query:

new FooQuery extends Kdyby\Doctrine\QueryObject {
    public function doCreateQuery(\Kdyby\Persistence\Queryable $repository)
    {
                $words = array("foo", "bar");
        return $repository->createQueryBuilder("sg")
            ->innerJoin("sg.tag", "g")
            ->where("sg.tag IN (:words)")
            ->groupBy("g.id")
            ->having("COUNT(g.id) = :count")
            ->setParameter("words", $words)
            ->setParameter("count", COUNT($words));

    }
}

Jakmile se vytvoří ResultSet, tak se zde query objekt předá ResultPaginator, který vždy provádí dva dotazy, prvním vytáhne ID a druhým je doplní do query - chápu smysl kvůli stránkování, ale v případě že není nastavený limit / offset, pak je to zbytečné provádět tuto query?

A tedy druhý podstatnější problém, je ten že v případě doplnění ID IN, do druhé query vytvoří dotaz, který nevrátí žádné výsledky.

V tuhle chvíli tedy, aby toto bylo funkční to řeším tak, že metodu doCreateQuery udělám veřejnou a poté jí předám DAO a na jejím návratové hodnotě pak zavolám getResults, namísto klasického předání metodě fetch.

Napadá mě možnost, že by to šlo vyřešit právě upravením ResultSet, který by v případě že není nastavený limit/offet získal výsledky přes metodu getResults a neproháněl to zbytečně přes ResultPaginator.

Ale za tolik do toho nevidím, čili si nejsem jist, jaká to má úzkalí.

Vítek

Please add some simple way to create connection to database during compilation.

I am trying to update with composer, but I end up there where I ended up months ago - Class Nette\Config\CompilerExtension has been renamed to Nette\DI\CompilerExtension.

In my composer.json, I have

"kdyby/doctrine": "@dev",
"nette/nette": "@dev",

doctrine/common           2.3.0              Common Library for Doctrine p...
doctrine/dbal             2.3.4              Database Abstraction Layer
doctrine/orm              2.3.4              Object-Relational-Mapper for PHP
kdyby/console             v1.1.4             Symfony Console integration f...
kdyby/doctrine            v0.9.3             Doctrine integration into Net...
kdyby/events              v1.2.3             Events for Nette Framework
nette/nette               dev-master f36f5da Nette Framework - innovative ...
symfony/console           v2.3.3             Symfony Console Component

I can't figure out how to update. When i tried to force kdyby/doctrine to use "kdyby/doctrine": "dev-nette-2.0" (from packagist), this is what happend:

C:\xampp\htdocs\smsh>php composer.phar update
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for kdyby/doctrine dev-nette-2.0 -> satisfiable by kd
yby/doctrine[dev-nette-2.0].
    - kdyby/doctrine dev-nette-2.0 requires doctrine/orm 2.4.*@rc -> no matching
 package found.

Potential causes:
 - A typo in the package name
 - The package is not available in a stable-enough version according to your min
imum-stability setting
   see <https://groups.google.com/d/topic/composer-dev/_g3ASeIFlrc/discussion> f
or more details.

Read <http://getcomposer.org/doc/articles/troubleshooting.md> for further common
 problems.

Am I doing anything wrong? :(

Hi,
I've just found this problem. When using default metadata cache (Kdyby\DoctrineCache\Cache) first load is ok, but next load throws an exception:

The annotation "@Doctrine\ORM\Mapping\Table" in class ...

It seems that metadata are not cached correctly.

http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/events.html#entity-listeners

I think, that this validation should not be so strict https://github.com/Kdyby/Doctrine/blob/master/src/Kdyby/Doctrine/DI/OrmExtension.php#L254

I'm trying to use Gedmo softdelete with rixxi/gedmo, but if I enable only soft delete there, method getEntityMappings returns emty array and validation error shows up...

Or am I missing something? :-)

Čauky Filipe,

našel jsem asi menší bug, v případě jednoduchého volání metody findAssoc nebo findPairs, v případě že předám do parametru $criteria asociativní pole, kde je nějaká závislost na jiné entitě, dostanu chybu "Invalid parameter format, : given, but : or ? expected" .. toto jsem u sebe vyřešil zatím jednoduše:

Namísto původního dotazu:

        $query = $this->getEntityManager()->createSelection()
            ->select('e')
            ->from($this->getEntityName(), 'e', 'e.' . $key)
            ->where($criteria)
            ->createQuery();

Mám nyní:

        $query = $this->getEntityManager()->createSelection()
            ->select("e.$value", "e.$key")
            ->from($this->getEntityName(), 'e', 'e.' . $key);

        foreach ($criteria as $column => $parameter) {
            $query->where($column . " = :" . $column)
                ->setParameter($column, $parameter);
        }

        $query = $query->createQuery();

V podstatě tedy jde o to, že Doctrine2 sama o sobě nepodporuje asociativní pole ve "where" pokud vím (?) a parametry vždy váže zvlášť přes setParameter .. tohle tedy asi řeší tvá nástavba nad Kdyby, avšak nyní mi to tedy nefungovalo a toto přepsání je nejjednodušším řešením.

Code

Current state is that insert quotes and update and delete don't.

Either all functions should quote or it should be delegated to utility class DirectDataPersistor<insert,update,delete> (preferably with better name).

#238

In EntityDao class are methods findPairs and findAssoc, these methods has $criteria parameter, which is array of conditions, but it need format of array:

$criteria = array("e.foo" => 1, "e.bar" => 1, ...);

Alias "e" is nessesary but I think that isn't excepted behavior. These methods has next parameters like "key" and "value" and in this is alias add automatic.

I suggest add to the methods something like this for adding prefix:

        foreach ($criteria as $col => $val) {
            $criteria["e.".$col] = $val;
            unset($criteria[$col]);
        }

This format is more excepted:

$criteria = array("foo" => 1, "bar" => 1, ...);

It does not save relations which are specified as unique and not NULL.

Čauky,

po delší době jsem udělal composer update, a rozhodilo se mi Kdyby/Doctrine - používám jak @stable verzi Nette, tak i tedy @stable verzi Kdyby/Doctrine.

1. Vyhazuje to vyjímku o neexistenci metody setInject, což jsem se díval, tak to bylo řešeno zde přes extensionMethod

Ale to již v kódu nyní chybí.

2. Když jsem si tuto kompatibilitu takto přidal, tak jsem našel další problém s kompatibilitou a tj. neexistence třídy 'Nette\PhpGenerator\Helpers'

Nejsem si tedy jist, zda-li se někde nesmíchala větev pro stable a dev verzi nette, či se už stable verze nette zavrhla či že bych měl problém u mě?

Díky za info

Single scalar results are not supported currently. Maybe add fetchOneScalar?

If there is an embedable entity inside another entity, the EntityRepository::find*By() should behave correctly and it shouldn't try to create joins for it.

• the result should not execute one query twice when ->getIterator() is called
• ->count() should initialize the inner collection and return the count after pagination

Generating autoload files, RuntimeException: Could not scan from classes inside "src/Kdyby/Doctrine/exceptions.php" whitch does not appear to be file or a folder

Use of undefined constant NETTE_DIR - assumed 'NETTE_DIR'

If you could resolve these dependencies, that would be awesome. We are comfortably using kdyby/[email protected] with Nette 2.2, but when I tried to update to your latest version, Composer stopped me. Thanks in advance :).

• limit the required nette/* to absolute minimum

I get:

VALUES (?, ?, ?, ?, ?)

• the driver is "stupid" and to get list of classes in any given directory, it requires all the files before it actually checks if there are any classes at all
• by bad configuration, the AnnotationDriver can require files, that contain no classes, for example if you pass it plain %appDir%, it will require app/bootstrap.php and check if there are any classes
• if you happen to have 5.3 and traits in your project, the driver will recursively require those files and most likely event the files with traits, this results in fatal errors