Better fields conventions definition

[foxycode]

I am used to write fields conventions using annotations in Doctrine. In Nextras\ORM I can only use Mapper which is confusing for large databases. Of course I can write few classes which will help, but I really think this should handle ORM alone.

I have lot of databases where I can't change it's structure, but want to make my work with them little bet sane by mapping each and every column name. It's the only way, because in these databases there is no convention at all, even index names and relationship tables are named in many ways. Is there any better way how to handle this thing or is there a plan to make it better.

As last thing, I would be much easier to write code for creating and updating database from model if conventions will be in annotations.

[hrach]

You can write your general storage reflection and use it in your BaseMapper that other mappers will reuse. IStorageReflection

You can also extend the abstract storage reflection which will let you define such basic conventions. See:

• StorageReflection
• CamelCaseStorageReflection
• UnderscoredStorageReflection

[hrach]

Feel free to ask and discuss what is insufficient in the current solution. Open to reopen :-)

[hrach]

Oh, I read it quite badly. Sorry, I see you are not asking for better reflection, but you don't want to define it in Mapper layer. Currently, I do not plan to implement definition support in modifiers, entities, but it could be pretty straight-forward to implement it by itself.

[hrach]

which is confusing for large databases.

Why is it confusing? Entity isn't tied up with db table. That's the reason.

[foxycode]

I'ts confusing because when you write all mappings in Mapper, it gets really big. It would be nice if there was a way to define them not in php code, best by entity properties.

I'd like to use ORM, but today it's pain for me. I can help with implementation if you can point me to right direction which you be willing to merge.

[hrach]

Why it should be big? It's the number of columns in the specific mapper, isn't it?

[foxycode]

It's the number of columns and it's all conventions for ManyHasMany and others. Even if it was short list, there is no simple way how to work with these definitions outside of mapper. For example I used them to validate input in API calls.

[hrach]

. For example I used them to validate input in API calls.

What? I dont understand this. You want to define mapping entity<->database and reuse it for validaiton of your API calls? How does definition in annotation will help you with this?

[foxycode]

I use annotation definitions in various ways because they are already there and I can parse them easily. If I create them in Mapper, how can I get to them? But that's not the main reason. I'd like to manage definitions in more practical way. So question is, will you help me with that?

[hrach]

I need to understand your usecase. I'm not definitely against, but your current position isn't clear to me. Moroever, I'm not sure you are doing it right.

[foxycode]

I don't know how to tell it better. I simply using property to column name mapping in whole application, not just for ORM.

I use naming to return proper fields on API because I don't use ORM on API. Still I want to have my property names on API reather than database one. Why should I define them on another place, when I have them defined in Doctrine annotation? It's easy to read them.

I use datatype from Doctrine annotations to validate user filter input on API calls. Once again, why define them on another place?

And this is only one example. My point is have these mappings defined on one place in easy readable way. If I do it as code in Mapper, they will not be. Not without invention of few classes that take them away from mapper and mapper will use them. I can definitely do it, but than everyone who uses ORM will do it own way, there will be no convention. I'd prefer some.