Drupal 查询生成器
我经常使用 Drupal 的视图模块来构建 SQL,并将其粘贴到我的代码中。它很好地理解 Drupal 数据库模式。
是否有一个模块可以为我提供此功能,或者我可以将其从视图中分解出来吗?
I quite often use Drupal's Views Module to build SQL that I paste into my code. It understands the Drupal database schema quite well.
Is there a module that would give me this functionality or can I factor this out of Views?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
扩展视图模块以更好地支持编程使用会很酷,但在那之前您可能想看看我的一位同事尝试创建类似于这样的东西: http://github.com/hugowetterberg/query_builder
与此相关的可能是服务项目尝试将视图数据提供为服务,这一努力我们现在正在分离成它自己的模块: http://drupal.org/node/709100可能值得关注,因为它需要对视图进行某种程度的编程访问。
以编程方式访问视图的模块的另一个示例是 Development Seeds Litenode:http://developmentseed。 org/blog/2009/feb/4/litenode
2010 年 12 月 15 日更新:EntityFieldQuery 几乎就像以编程方式使用视图来构建查询 - 区别在于 EntityQueryBuilder 仅适用于实体和字段,而且还有一个好处是它实际上可以针对使用中的任何类型的字段存储构建查询 - 例如。像 MongoDB 这样的 NoSQL 数据库。示例可以在这里找到:http://drupal4hu.com/node/267
Would be cool of the Views module was extended to better support programmatic usage, but until then you might perhaps want to take a look at one of my colleagues attempt at creating something similar to such a thing: http://github.com/hugowetterberg/query_builder
Related to this might be the Services project attempt at providing Views data as a service, an effort that we right now are separating out into it's own module: http://drupal.org/node/709100 Might be worth follow since it's going to need some level of programmatic access to Views.
Another example of a module that's accessing Views programmatically is Development Seeds Litenode: http://developmentseed.org/blog/2009/feb/4/litenode
Update 15/12-2010: The EntityFieldQuery in Drupal 7 is almost like using Views programmatically to build queries - the difference being that EntityQueryBuilder works on only entities and fields and by that also with the bonus that it actually can build queries against any type of field storage in use - eg. a NoSQL database like MongoDB. Example can be found here: http://drupal4hu.com/node/267
虽然这不是理想的处理方式,但您可以按如下方式获取视图的结果:
这样,每当您修改视图查询时,都不必重新复制代码。我确实同意视图需要分为查询构建 api 和 UI。
Although this isn't the ideal way to do things, you can get the results of a view as follows:
This way, whenever you modify your views query, you don't have to re-copy the code. I do agree that Views needs to be split up into a query building api and a UI.
是的,我认为视图是了解当前字段使用哪些表的最佳选择,因为许多模块(以及视图中的更多模块)都有钩子函数,它们提供有关此字段、表以及与其他表的连接类型的一些信息。
您还可以通过以下方式阅读表格和字段的方案:http://drupal.org/project/schema< /a>
Yes, i assume views is the best to know what tables are used for current field, because many modules (and more in views) have hook functions, that provide some information about this field, table, and connection type with other tables.
Also you can read scheme of tables and fields via: http://drupal.org/project/schema
我很好奇 - 为什么你会使用视图来构建 SQL,然后不使用视图?
当涉及到更困难的事情时,例如多对多关系、GROUP BY、COUNT、SUM、子查询等,无论函数需要什么,最好自己编写(特别是如果 contrib 模块没有视图支持,并且您需要的不仅仅是节点)桌子)。
对我来说,当视图无法完成任务时,我会编写一个简单的模块,该模块调用 hook_menu (以注册路径)以及执行我需要的查询的回调。
I'm curious- why would you use Views to build SQL, and then not use Views?
When it comes to more difficult things like many to many relationships, GROUP BY, COUNT, SUM, subquerying etc whatever the function calls for, it's best to write it yourself (especially if contrib modules have no views support and you need more than the node table).
For me, when Views can't get it done, I write a simple module that invokes hook_menu (to register the paths) with a callback that does the querying I need.