July 2006 - Development - lists.drupal.org

Core query object?
by Scott Reynolds 22 Jul '06

22 Jul '06

I was pondering this idea for my cre module. I am thinking about creating a query object that would allow me (like the views one does) to add where clauses and select different columns from different tables and do joins etc. This would be useful for instance when recommending comments on a particular node. I would do something like (Plz ignore any mistakes in the code...) comment_recommendation_recommendation_hook(&$query_obj) { query_obj->add_table('comment'); query_obj->add_where('comment.nid = ' . arg(1)); .... } So it occured to me, is there such an obj in core and if there isnt should there be one? I am not purposing to remove db_query and etc but rather an object that implements those methods. Another dreaded layer of abstraction.... ~scott

1 0

Drupalized Movielens 1 million votes -- need speed help
by Scott Reynolds 22 Jul '06

22 Jul '06

Hello, I have taken the time to drupalize movelens 1 million vote database. I am using it to test my recommendation engine. http://drupal.org/project/cre You can find the drupalized stuff and the java program that created it in my sandbox contrib/sandbox/scottreynolds I am posting here because, as one would expect, it takes awhile to query the database. Looking for ideas on how to speed it up. Here is the query that selects the recommended content. $db_result = db_query("SELECT d.content_id1 as 'content_id', sum(d.sum+d.count*r.value)/sum(d.count) as 'score' FROM {votingapi_vote} r, {cre_similarity_matrix} d WHERE r.uid=%d AND d.content_id1<>r.content_id AND d.content_id2=r.content_id AND d.content_type1='%s' AND d.content_type2=d.content_type1 AND r.tag='%s' GROUP BY d.content_id1 ORDER BY score DESC",$uid,$target_type,$tag); If you would like to get involved in the project or follow my progress or whatever ( i love to generate more interest) join my groups page: http://groups.drupal.org/soc-content-recommedation-engine

1 0

Re: Caching, caching, caching
by Ken Rickard 22 Jul '06

22 Jul '06

With the new path_alias handling, it seems that the biggest gain is in cutting the volume of sql queries. The stuff I did in 4.6 was (again) very specific and based on the settings I used for Pathauto. Perhaps we could write an advanced path.module settings page that lets site admins turn of alias lookups for specific path types -- where a path type is defined, essentially, by arg(0). I can think of the following paths that might qualify: - node - comment - admin - taxonomy - user - blog This wouldn't require regex lookups on-the-fly, and would be turned off by default. But it might allow me to say: only do the following path lookups. The gain is minor on small sites, but not large ones. Drawback (and there may be more): Might need a module hook to let module 'register' themselves with path.module's settings. -Ken Rickard agentrickard

2 1

RFC: moving issue tracking into separate module
by Derek Wright 22 Jul '06

22 Jul '06

http://drupal.org/node/74995 => move all issue tracking into a separate module http://cvs.drupal.org/viewcvs/drupal/contributions/modules/ project_issue/ from the intro to the issue: > for all sorts of reasons, we need to move the issue tracking > functionality out of project.module and into a separate, smaller, > more focused module ("project_issue.module"): > > - ability to use project with either project_issue or casetracker > - possiblity to use project with an entirely different issue > tracking system (see http://groups.drupal.org/node/1047) > - keeping the code in smaller pieces so it's easier to work with > and understand > - developers can more easily focus on either the issue tracking > stuff or the project nodes/releases/downloading stuff, depending on > their itch reviews and comments, please! thanks, -derek (dww)

1 0

link between index and content
by UN PEP 22 Jul '06

22 Jul '06

Hi I'm newbie in php and i'm looking for the code that link between index and content page.When we click on the navigation menu, it goes to the appropriate content page depends on the type that we click (i.e node, flexinode, page, story etc...). But i could not trace how they were linked from the index page. (e.g when we click "http://localhost/aaa/index.php?type=flexinode-4", it should be display the content written in flexinode-4.) Can anyone help me to explain a draft overview of the drupal in which how the content page link with index according to the type that user selected? I would very much appreciate if anyone can give me a helping hand. Thanks in advance. --------------------------------- Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail Beta.

1 0

Re: [development] Have you ever laughed fate in the face?
by Chad Phillips -- Apartment Lines 22 Jul '06

22 Jul '06

On Jul 17, 2006, at 2:40 PM, Neil Drumm wrote: > I think this is a good change. Forgiveness is a good thing to have. > But > it simply can't be added without people looking at it. Same goes for > every other feature. just to put everybody in the loop here: chx and i have been discussing the idea of a deletion API for drupal core, which would address killes' modular concerns as regards this functionality, as well as allow us to break out all the confirm code into a seperate module. what this means is that site admins would have the following options for a deletion workflow: 1. the current scheme: no trashbin, with confirm screens 2. trashbin with confirm screens 3. trashbin with no confirm screens 4. no trashbin, no confirm screens (for those who like to live dangerously!) simply enable or disable either of the confirm.module or trashbin.module to get the desired combination. in addition, the API would provide non-core modules with greater access to the core's deletion cycle (which is currently fairly closed) i've already begun work on this, and my goal is to have this up for testing within one week, if all goes well. in the meantime, i would still love to get reviews of the original trashbin patch, as most of that code will be used in this new API schema. patch is located here: http://drupal.org/node/35422#comment-115495 test site is located here: http://undo.xcarnated.com/

16 32

deletion API summary, question
by Chad Phillips -- Apartment Lines 22 Jul '06

22 Jul '06

as i mentioned a short time ago, i've been trying to flesh out a deletion API for drupal. i thought i'd take a few minutes and discuss it's current state, and throw out some unfinished business to get perspective from other developers. in working on the trashbin patch, i discovered that it's helpful to think of deletions as happening in packages. when you delete a node, you don't just delete something from the node table--there are related node tables, then hook_delete calls, then nodeapi delete calls (and possibly other calls initiated from the last two in that list). deletions in drupal proceed from the top down, recursing until all items are deleted. that's what i'm calling a package. my current work is based on that viewpoint. package deletions are started with a call to a helper function (called drupal_delete_package at the moment), all relevant deletion operations are passed into the package via drupal_delete, and then packages are deleted via another helper function (drupal_delete_execute). once a package is compiled, there are two hooks that are called: hook_delete_pre -- this is an opportunity for modules to throw objections to a package deletion. any module calling this hook will have access to the information in the entire deletion package, and can throw two kinds of objections: confirm and abort. hook_delete_execute -- this is an opportunity for modules to perform any last minute operations before the package is deleted. for example, a trashbin module would use this hook to store metadata about the package deletion. workflow is as follows: 1. call drupal_delete_package to start the package 2. call drupal_delete as many times as is necessary to fill the package with deletion data 3. call drupal_delete_package again if you wish to start a new deletion package in the same page call (like for admin/node multi- deletes) 4. call drupal_delete_execute to execute the deletion of all packages 5. hook_delete_pre is called, and modules put in confirm and abort objections 6. if there are any confirm objections, then a confirm screen is generated 7. once confirmed, the packages are resubmitted 8. any packages with abort objections are skipped, and warnings are issued 9. remaining packages are deleted whew! the important remaining question: how are we to perform the actual deletions? do we delete the data from the table, or merely mark it as deleted with the addition of a 'deleted' column to all tables? if we're going to take the latter approach, it's important to note that we can't just have a DELETED flag--we need some way to know which deletions belong to which packages, otherwise it's a real mess :) my suggestion is to record a unique package id in the deleted column for each deleted package. sorry for the long post--this is a big job and a relatively complex feature--there's a lot to say! chad

5 4

RE: [development] Drupal Multi-Site Management
by Boerland, Bert 21 Jul '06

21 Jul '06

-----Original Message----- From: development-bounces(a)drupal.org > Not "in the process of" -- it is open source under the GPL. We have > protected access to the repository at the moment. Contact me for access. Good to see more code comming in! Do you mean restricted access to cvs or restricted access to d/l this module at all? Since I (and serveral other people [1]) looked for it but cant find it. If the restriction / "protected access" holds true for d/l a GPLicences software package, you might get into legal problems. See section 2 of the OSS definition ("there must be a well-publicized means of obtaining the source code") [2] and I dont think a shout out on this ml is qualified as "well-publicized". Then again, IANAL. [1] http://drupal.org/node/65896#comment-124595 [2] http://www.opensource.org/docs/definition.php

3 2

Re: [development] Have you ever laughed fate in the face?
by Chad Phillips -- Apartment Lines 21 Jul '06

21 Jul '06

On Jul 21, 2006, at 3:52 AM, Derek Wright wrote: >> Adding an extra where-clause to all queries is perfectly valid if >> that is the best solution from a technical point of view. We >> shouldn't go with a solution that is sub-optimal, and avoid a >> superior solution just because it is a lot of work. That sort of >> decisions tend to backfire in the long run. > > if we're going to generate a patch that touches "thousands of > queries" and test the results, the "best solution from a technical > point of view" seems to be to port all said queries to some kind of > query building interface so we never have to touch them again for > this kind of thing... i couldn't agree more. my understanding is that we don't have that at the moment because SQL queries are easier to read in the code, and possibly because it's a little more efficient. the efficiency argument i understand, but we really wouldn't know what we're giving up until we tested it. the readability argument is shortsighted in my opinion--it puts us in this kind of position, where somebody has to muck through all the code and fix everything by hand, which seems unnecessary--not to mention more bug-prone and less flexible. in this sense we're really talking about a format change, and i think developers would have little problem getting used to a new way of reading the queries in code. not to mention that if you want to see what the final SQL looks like, just pop open the devel module and turn on the query print thing. :)

1 0

Re: Caching, caching, caching
by Ken Rickard 21 Jul '06

21 Jul '06

In the 4.6 model -- even with the backport url_alias patch -- I altered drupal_lookup_path() to disallow any lookups that didn't come from path aliases. Since I set the rules for that site, it meant paths were only checked if: 1) $path == 'taxonomy/%' 2) $_GET['q'] == $path This prevented the menu, node links, comment links, et. al. from being processed. It cut path lookups from 200+ to under 10 for node page views. Now this isn't a universal solution, but it may suggest a plan. - Ken Rickard agentrickard >>> Maybe we should run the modified devel.module on drupal.org to >>> see what the most expensive queries are? >> >> SELECT * FROM url_alias, I'd be surprized if that had changed. The >> individual query is very short but there are probably 120 per page >> on average. > > Are there reasonable assumptions we can make about certain URLs? > Like, can we assume that people don't want to alias '?q=qcomment/ > reply/123'? Or ?q=contact? Or q=user/register and ?q=user/ > password? If we can make some simple assumptions, we might be able > to save a helluvalot database queries (per page view) ... Food for > thought. Any thoughts here?

1 0