Also, this is kind of long.)

I have the following association set that represents a document repository.


User 1-n Folders
User 1-n Roles
Folder 1-n Documents
Documents n-n Brands


Folders n-n Viewer Roles
Folders n-n Manager Roles


Lastly, Users n -(polymorphic through)- n Brands

In order to display a tree of Folders a given user can view, that User must
be a manager or viewer of a Folder, and his Brands contain Brand of at
least one Document under that Folder (a Document associated with a Brand under a folder lets the user view that Folder iff that user has the Brand.)

So the way this was originally implemented was a recursive loop
something like this:

def show_subfolders(folder)
User.folders.each do |folder|
show_subfolders(folder)
end
end

Class User
def folders
Folder.find(:all,:conditions => ‘parent = folder’,
:include => [:manager_roles, :viewer_roles, {:documents => :brands]]
).each do
|folder|
if method_to_check_brands(folder) && method_to_check_view_perms(folder)
yield(folder)
end
end
end

The eventual problems that developed with this logic were the following:

1. second-level includes are problematic in Rails, this generated
   outer joins against seven tables
2. massive join, recursively called. I believe the Big O* is (c!)^n,
   glancing quickly
3. Indexes don’t help, because the outer joins sort of blow the
   performance gains away
4. All data is being selected, so just sheer amount of data transfer
   slowed things down
5. The yield adds a lot of crap to the callstack
6. Brand and View/Manage permissioning was already happening in the code

With 245 documents under 30 folders, mysql logged slow queries that
had to examine 320,000 rows — and that was multiple times.

The solution? Remove the :includes. Since permissioning and
restriction was already happening in code, I let Rails do its own
thing and select when necessary. This lowered the response time from
10+ seconds for page view to 0.5 seconds. (And for what it’s worth,
doing the join statements manually, or removing the second-level :includes only brings it down to 2 or 3 seconds.)

By reducing the stuff that needs to join, indices are are used more
efficiently, and letting Rails do a find for Folder.documents on each
iteration ends up being a lot faster than trying to join with the
view/manage/brands permissions.

The More You Know!

* It’s been over a decade since I actually figured out the order of an algorithm. I’m sort of guessing, here.

Well, here’s a quick and dirty migration that’ll save you from moving files manually.

Automove Files for Storage Changes, with acts_as_attachment

Originally I wanted to do something like Attachment.new( OldAttachment.find(?).attributes ), but there were issues with that because acts_as_attachment wants uploaded data to be a tmp file or some crap. This ended up being the easier way, all in all.

Use with care.

You will notice that in my screenshot, the final function call to ‘list_cats’ at the end is truncated. This is because there are eighteen parameters. Again with the clicking.

Also, there’s an awesome feature in the WP DB object such that if one requeries the same table on the same page, apparently pagination offset is lost. This means that the main index page listing posts cannot also have a recent posts list — because you either will have recent posts starting with whatever the main list offset is, or you will only ever have as many posts on the index page as the recent posts query returns.

WIN!

Since Paypal purchased Verisign they are discontinuing the pfpro extension to PHP. And in fact, what I’m reading is that Sept 2009 is the end of life for that functionality, meaning requests will not work beyond that point.

For sites using pfpro that ned to transition, the solution is
1) use the java sdk
2) use the .net sdk
3) write your own api to utilize curl and https
4) use a public api for curl and https a la This post from the paypal developer forum

ALSO…
this means if you’re installing a 64 bit system, you’re pretty much screwed because there are no new libraries/binaries released for pfpro under that platform… unless you’re running a .net or java solution.

Sucks.


map <desiredkey> <targetaction>

So, for example, I split windows vertically and want to navigate via ctrl+pagedown or pageup.

Here’s what I did (include < and > when defining)

map <c-pageup> <c-w>h
map <c-pagedown> <c-w>l


Found via a vim wiki search
[ad#Google Adsense small leaderboard]

This will generate an HTML version of your source code, complete with color scheme. It’s pretty sweet.

Example here (opens a new window)

This just tickles me.

Situation, selecting the first 3 Announcements for particular User Roles at a particular Organization.

There is an announcement table and a meta table containing org/role join information.

The (somewhat crappy) query is like so:
SELECT TOP 3 b.announcement_title FROM announcements b
WHERE b.anouncement_id IN (
SELECT
  DISTINCT a.announcement_id
FROM
  announcements b, announcement_role_org aro
WHERE
  aro.announcement_id = b.announcement_id
   AND
  aro.role_id = $role_id
   AND
  aro.org_id = $org_id
)


Yes, I know it should have been written as a join.

This is the problem:

• When the outer select says TOP 3, the server chugs forever and doesn’t return a result (at least, doesn’t return a result within 2 minutes, I killed the select after that time limit).
• When the outer select says TOP 5 or TOP 6, it returns results fairly instantly

WTF?
For the record, the inner select for the $role and $org I specified only ever return 6 results.

Oh, lastly… if I say NOT IN (returns 210 results), it doesn’t seem to matter what TOP value I have.

WHY???