LPS-31133 and LPS-31033 #7812
LPS-31133 and LPS-31033 #7812
Conversation
|
Hey Shuyang, I merged your changes for LPS-31133 with some minor changes (please see Git log) But I did not merge LPS-31033. I think the fix is incomplete at best. For example, in places where you put in "sqlQuery == true", you properly append a "_" to the parameters, but the select statement itself is not "appended". See _FILTER_SQL_COUNT for an example. Technially, the primary key of the table could require a _ Thx |
|
Also, I have a doubt that LPS-31033 should make StructurePKComparator break. Because even the order by references it by "id" and not by "id_" Also, see LPS-18827's change to persistence_iml.ftl. It makes me wonder if we just need to fix it by changing it to DBName? Then it's a much smaller fix. But if we did, it makes me think that StructurePKComparator won't work... So I feel we need to investigate this one more. Thx! |
|
Also see LPS-3461 |
|
Merged. Thank you. View just my changes: shuyangzhou:852fa16b93...a836a48 |
|
I will do more dig around to find a better solution for LPS-31033 |
|
Why don't we just use DBName? SQL can not contain certain bad logic column name, but HQL can use all escaped SQL names. We can use name for model_.ftl to generate entity class, but for mapping and persistence_.ftl we just all use DBNames which are safe for both HQL and SQL. It may look ugly for HQL, but it's generated code, as long as the logic is working fine, who cares the names. |
No description provided.