在创建实体管理器之前，我有这行代码：
breeze.NamingConvention.camelCase.setAsDefault();
和这个查询：
var query = entityQuery.from('vehicle')
.expand("engine, driveType")
.select("engine.friendlyEngineName, driveType.friendlyDrivetrain")
数据回复如下：
driveType_FriendlyDriveTrain = "Rear Wheel"
engine_FriendlyEngineName = "6.2L V8"
为什么“FriendlyDriveTrain”和“FriendlyEngineName”PascalCase？这似乎显然是错误的，因为我在创建EntityManager和查询之前设置了camelCase。如何制作它以使'_'之后的部分也是camelCase？
注意：我确保删除所有网络API ji格式配置，以便breeze是唯一管理翻译的人。
编辑：奇怪的是，同样的查询在点击缓存时返回'_'后面的camelCase属性。所以同样的查询，两个不同的结果。
答案 0 :(得分：0)
请查看documentation on NamingConvention。如果这不清楚，你可以回来问一个更具体的问题。感谢。
还请解释您认为Breeze应该使用“_”字符做什么。 Breeze惯例将其视为任何其他标识符字符（例如，a-z，A-Z，0-9）并且不对其执行任何操作。您似乎希望您的约定跳过前导下划线，并且如果它是alpha，则降低后面第一个char的大小写。我想你也想放弃下划线......但我不确定。
那很酷。您可以编写自己的NamingConvention，它可以满足您的需求。你也可以把它作为默认值。事实上，NamingConvention文档页面上显示的noUnderscoreConvention已经超过了回家的一半。
我会说你扔了一个循环，在select语句中混合了句点和下划线并返回数据。我不知道你是如何选择工作或得到那样的结果。
好的......我忽略了你正在进行 投影 的事实！
投影展平虚线属性路径值（无论是ComplexType还是EntityType导航）。它通过使用“_”作为分隔符来为这些“扁平属性”创建投影属性名称。是的，它将适用的MetadataStore命名约定应用于那些“_”分隔名称，是的，Breeze camelCase约定对下划线没有任何特殊处理。因此，您可以返回展平的投影属性名称，例如“engine_FriendlyEngineName”。
如果您愿意，可以将此称为错误。我不。我不这样做是因为（a）在我看来，在这种情况下，camelCase会议应该做些什么。 （b）永远是这样的; （c）我认为冒险破坏可能依赖当前行为的现有应用程序的风险并不重要......而不是当你的补救措施如此简单时。
而且补救措施是编写自己的camelCase约定，以不同的方式处理这些预测的属性名称。
请在撰写时将其包含在此处，以便与您分享观点的其他人可以从中受益。
我不确定你写的时候的意思：“这个相同的查询返回属于”_“的camelCase属性，当它到达缓存时。这有什么疑问？不是你在这里写的那个。
投影结果不会“点击缓存”...除非投影的属性值本身就是一个实体......而这不是这里的情况。你是什么意思“这个查询”。我在等你的回复。