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?
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
Although this isn't the ideal way to do things, you can get the results of a view as follows:
$view = views_get_view('search');
$view->set_display('main');
$view->set_items_per_page(0);
$view->execute();
$items = array();
foreach ($view->result as $row) {
$items[] = $row;
}
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.
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
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.
Related
I'm creating my main project functionality right now so it's kind of a big decision to make in my project, I want efficient & scalable solution. I use different API's to fetch users products ultimately for 1 collection to display products information inside a table with possible merge by SKU TITLE from different sources.
I have thought of 2 approaches (In both approaches we add Meteor.userId() to collection insert so each users has it's own products:
1) to create each API it's own collection and fetch the products to it, after or in middle of the API query where I insert it to sourceXProducts also add the logic of merge products by sku and add it to main usersProducts Only the fields I need, and we have the collection of the sourceXproducts if we ever need anything we didn't really include to main usersProducts we can query it and get it so we basically keep all the information possible (because it can come handy)
source1Products = new Meteor.Collection('source1Products');
source2Products = new Meteor.Collection('source2Products');
usersProducts = new Meteor.Collection('usersProducts');
Pros: Honestly I'm not sure, It makes it organized also the way I learned Meteor it seems to be used a lot.
Cons: Meteor collection joins is not supported in core yet, So I have to use a meteor package such as: meteor-publish-composite which seems good but this way might hit performance
2) Create 1 collection and just insert everything the API resonse has and additional apiSource field so we can choose products from X user X api.
usersProducts = new Meteor.Collection('usersProducts');
Pros: No joins, possibly better performance
Cons: Not organized, It can become a large collection maybe it's not good for mongodb
3) Your ideas? :)
First, you should improve the question. You do not tell us anything precise about your schema. What are the entities you have and what type of relations are there and what type of joins do you think you will be doing. How often you will be doing them?
Second, you should rethink your schema and think in the terms of a non-relational database. I see many people coming from SQL world and then they simply design their schema in the same way. Wrong. MongoDB is not SQL and things you learned there you should not try to just reuse here. You should start using features like subdocuments and arrays which can help you solve many basic things you would do in SQL with joins. So, knowing your schema would help us help you design the schema. For example, see this answer and especially the comments for the discussion for a similar type of question you are asking here.
Third, have you evaluated various solutions which exist out there? There are many, but you have not shown us that you tried any of them and how it worked for you. What were pros and cons of them, for you and your project?
Fourth, if you are lazy to evaluate, you can just use peerlibrary:peerdb and peerlibrary:related. They are simply perfect. You should trust me. I am their author.
My professor recently gave my class an assignment and I need help finding the tools to do so.
We have a database of tables (Customer, Payment, Order, etc.) and I need to use Drupal 7 to allow users to see customer's info, view customer data (i.e. payment history), or edit customer information. This would involve select statements, aggregate clauses, joins, etc. It would also involve forms to input customer name/information.
Here is the catch: I am not allowed to write any code. That means no API, no SQL queries, and no PHP. I am only allowed to use ready-built modules.
So my questions is: What module(s) should I use, and how do I use them?
I know the view is a good place to start, but the default options of view are for content. I have tables on a database, not content. Also from what I understand, custom queries of view require coding.
I believe this is what you are looking for:
http://drupal.org/project/data
If it integrates with the Views module properly, then you won't be required to do any hand-coding to make a View which queries your tables.
(Disclaimer: I haven't actually used it)
This relates to Drupal 6 and Views 2.
I'm not new to Drupal, but I am new to problematically using Views.
I have a custom view defined in a module which is integrated with data like this (I think):
$view->base_table = 'tblName';
I am integrating a third-party API. It returns me a pretty vanilla PHP object.
I need a way for list returns from that API to become the base_table for the view, on the fly. Is this possible? The ugly solution I was think of was making every return item a node, and then using those as the "base_table". I think that would work, but it seems ugly. I don't want a bunch of nodes hanging around for later.
Any suggestions? Thanks.
I'm not sure this is a good idea, but I ended up creating a routine based around Drupal's caching mechanism. I'm droping and creating a table on the fly and handing that table to Views. The table is populated every five minutes by the API. It can be forcibly re-populated by clearing the Drupal cache.
I tried using MySQL Temporary tables, but they didn't persist well enough. I wonder if there is a way to make them more connection-persistent, or to last a certain amount of time.
Im currently evaluating Drupal to see if we can use it to replace our framework. My problem is I have this legacy tables which I would want to try to reflect in Drupal. It involves a join table. There's quite a lot of this kind of relationship in our existing web app so I am looking for possible ways to solve it.
Thank you for your insight!
There are several ways to do this, and it's hard to know which is best with no context about what you're actually doing with the data, but here are some options:
One way to do this is to make a content type representing each table (using CCK) with the foreign keys represented by type-specific node reference fields. Doing everything as nodes gives you a bunch of prebuilt functionality around nodes, but has a bit of overhead you may want to avoid.
Another option is to leave your database just like it is now. Drupal can do direct database queries, or you can use Data to expose your tables to Views.
Another option, if those referenced tables really only have 1 non-ID field, is to do the project_companies_assignments as nodes and do the other 3 as taxonomies. But this won't work if those are really more complex entities, and wouldn't be very flexible if they might become more complex.
What about using hook_views_api and exposing your legacy tables in hook_views_data? i tried something like this myself - not sure if that is what you want...
try and let me know if that works for you.
http://drupalwalla.blogspot.com/2011/09/how-do-you-expose-your-legacy-database.html
Going with Views and CCK, optionally with the additional Data module has one huge disadvantage: it comes with complexity.
My preferred alternative, is to write your own module. Drupal offers little help wrt database abstraction, it comes not with a proper ORM or such. But with some simple CRUD functions for the data in the database, a few simple forms in front, and a menu-callback with some pages to present the data, you can -quite often- get your datamodel worked out much faster then going the route of the overly complex, often poorly documented CCK and views modules. KISS.
What's the "right" way in Drupal to create reports? I was hoping to use a view but am not having much luck. My goal is to create a table of rows containing three fields: user name, location, SUM of volunteer hours. Once I have this part working, I plan to expose filters for Location and Date.
Views Calc only allows you to group by one field. I know Crystal Reports and MSSQL Reporting Services and I was hoping to find a similar kind of thing for Drupal. Is there a framework, examples, or a module to help with this, or do I need to write a custom module implementing the views_alter_SQL hook to get the desired data for each report?
EDIT: I ended up getting it to work with BIRT reports, which gave a lot more power than Views could allow. Code is on my blog: http://nicholaiburton.com/blog/2010/creating-custom-reports-for-drupal
You could implement a views_query_alter but you might be better off implementing a custom views field handler, because I assume that your user.uid joins to hours.uid. This will probably be your best long term solution.
All you'd need to do is just tell views how your tables join and define the handler for the total hours. You can find help/docs -> http://views-help.doc.logrus.com/help/views/api
in any way, for Sum of Volunteer hours you need to build custom module, so building custom query more simpler, than attaching custom field to Views via it's hooks...