Allow user defined entity annotations

[Keeehi]

Zatím jsem na projektu používal kdyby\doctrine. Ovšem při pracování s relacemi pokládá neefektivní dotazy, proto zkouším tento projekt. Co mi tu chybí je možnost vygenerovat si SQL dotazy které by podle entit vytvořily odpovídající databázové tabuky. Tak jsem si řekl, že bych mohl být zase jednou světu prospěšný a tuto funkcionalitu vytvořit. Tak jsem si s tím včera a dnes hrál a zjistil jsem, že nextras/orm na to úplně ještě připravené není. Jinak řečeno - chybí pár anotací které by byly potřeba. Chtěl bych tedy zjistit, zda to půjde nějak vyřešit. Je možné vytvořit a přidat nějaké anotace přímo do nextras/orm? Nebo bylo by možné vytvořit nějakou {user-options xxx} anotaci o kterou by se parser moc nezajímal a uživatel by si do ní mohl psát co chce, čehož by mohl využívat ten generátor. Vím, že tyto anotace nejsou pro běh nutné a stejně jako v doctrine by byly užitečné jen při generování. I když by vlastně podle některých bylo možné provádět validace tam, kde si programátor nenapíše vlastní setter.

[hrach]

Well. There is too much to comment.

I don't like automatic code generators. That means I tried to avoid them, but I understand, that basic ORM skeleton is quite huge and requires a little bit of writing. ORM entity metadata dosn't support much info, as you sad, because they are storage indenpendent. Different column nameing should be done on storageReflection level in mapper.

Personally, I would like implement it otherwise: generate basic php code structure from database structure. But it's just plan.

Let's understand this issue as issue to let you define own annotations. (This was in plan, but I see, it currently not so easy.)

[Keeehi]

I don't like automatic code generators. That means I tried to avoid them, but I understand, that basic ORM skeleton is quite huge and requires a little bit of writing.

I like them but don't trust them. I always revise what they give me. But I found out that doctrine generator gives really good results and there is not much to fix after. It can do the most of the boring simple and repetitive job quite good.

Different column nameing should be done on storageReflection level in mapper.

I am aware of that and my generator works with mappers. Even it was not always easy, I was able to work with them.

Personally, I would like implement it otherwise: generate basic php code structure from database structure. But it's just plan.

I feel it other way with ORM (in general, not only nextras\orm). And it comes from what you said: "ORM entity ... are storage indenpendent." So my definition of entity should be superior to storage. Definition of storage structure should be based on entity definition and not other way around.

In the highest level of abstraction, I want to say to my program: "Here is Object I have created. Store it and I don't care how you will do it. You need to create some structure in storage? Fine, I don't care as long as it works."

Right now, I am able to create working structure for mysql database but it is far from optimal. Those optimizations can be done with some additional user defined constrains of properties. Like maximum lenght, if the length is stable, uniqueness, if integer values can be negative etc. Those descriptors are not storage specific (well, they will be probably mostly used by databases). They describe constrains of properties. The biggest similarity I can see with nette forms and rules applied to inputs. They define some restrictions and values are validated against them. If there will be standard for it, setters could also take them to consideration and be more restrictive.

Let's understand this issue as issue to let you define own annotations.

More or less, yes. It is feature request for property constrains defined by annotations. Officialy supported by nextras\orm (prefered) or done trough own annotations.

[hrach]

Postponed to v1.1.0.