I've committed a change that adds function user_relationships_count_relationships($criteria = array()) to the public API. Here's the documentation:

/**
 * Public API for counting relationships that match specified criteria
 *
 * @param $array
 *    An associative array of attributes to search for. Keys in the array should match
 *    column names in the user_relationships table. However, as a convenience, you can
 *    also specify the following keys:
 *      'typename': match the rtid of the type with the given name (no join)
 *      'uid', 'uid1', 'uid2': match either the requester_id or the requestee_id
 *        Example: ('uid1'=>10, 'uid2'=>20) counts how many relationships exist between
 *          users 10 and 20
 *
 *    For the dates (created_at and updated_at), the first character of the value should
 *    be an operator, i.e. '<', '=' or '>'. The remainder should be the value, which can
 *    be either a (numeric) Unix timestamp, or a string formatted to match MySQL's
 *    date/timestamp format.
 *    e.g. 'created_at' => '>2006-12-31 23:59:59' to find relationships added in 2007 or later
 *
 * @return
 *    count of the relationships that match the criteria
 *
 */

Comments

sprsquish’s picture

Nice!

prfctns6@gmail.com’s picture

Glad you like it!

I'm thinking now that this function should be renamed and have the following signature: user_relationships_retrieve_relationships($criteria=array(), $count=FALSE). If you call it with the second argument set to TRUE, it behaves as the current _count_relationships() function behaves, i.e. it returns the count of the matching relationships. If you omit the second argument, it returns an array of the relationships that match the criteria. That way folks overriding theme functions are less likely to have to code their own SQL to fetch relationships. The code changes for the body of the function would be pretty minimal.

What do you think?

sprsquish’s picture

I think that'll make code difficult to read down the line.

user_relationships_count_relationships(array('foo' => 'bar')) is very clear. You're obviously asking for a number.
user_relationships_retrieve_relationships(array('foo' => 'bar'), TRUE) becomes pretty unclear. I read it as: give me all the relationships meeting my criteria, NOW.

If you're thinking it should be this way to combine the two functions to make maintenance easier for us, I'd create a private function something like _user_relationships_select($criteria = array(), $count_only = FALSE). Then call that through the api functions.

prfctns6@gmail.com’s picture

Good point. I won't do anything this week, but if the need arises to add a load_relationships, I'll do it as you suggest. Thanks for the feedback!

Anonymous’s picture

Status: Fixed » Closed (fixed)
toemaz’s picture

Version: 5.x-1.x-dev » 6.x-1.x-dev
Status: Closed (fixed) » Active

Apparently this user_relationships_count_relationships function was removed again during the 1.19 commit of the api module. Changelog says: merge DRUPAL-5--2 into HEAD
Was this removal by accident or was it on purpose. If by accident, are you open for patches to get it in again?

mercmobily’s picture

Hi,

I have the feeling the module is dead.
I am trying to get in touch with the maintainer about looking for a new maintainer.

Bye,

Merc.

toemaz’s picture

@mercmobily

Thanks for the notice. I guess it's a major set back if this module is really abandoned.
I just compared the internal workings of this module with buddylist and decided this one is much more better in terms of performance. E.g. buddylist loads the whole list on user_load whereas UG doesn't do this. For a pretty big website, buddylist would be consuming a lot.

Anyway, did you start a new issue regarding 'the search for a new maintainer'?

mercmobily’s picture

Hi,

For now, I am trying to get in touch with the maintainer, and talking to the infrastructure guys at Drupal.

However... this module is duplication. What they will tell us -- and they are right -- is that we ought to submit patches to buddylist2 in order to optimise it etc.

I think this module would have been a buddylist2 killer if the author hadn't thrown the towel on it. I agree, it really is nice. However, that's not what happened and I am starting to think that working on buddylist2 might be a better idea.

Merc.

ajayg’s picture

I agree this is much better designed module for scalability and used in a production website as author mentioned in the README file.
Too sad it is getting abandoned. Perhaps there is some interest from ourchart.com (production website)

mercmobily’s picture

Hi,

I developed a replacement for buddylist and user relationshiop;
I am finishing the UI as we speak.

Please ping me in a couple of days about it.

Merc.

ajayg’s picture

@mercmobily you mean a totally different module? What about users who already have UR? A migration path? Have you given thought for updating/forking UR itself?

mercmobily’s picture

Hi,

I don't mean to sound like a snob, I won't touch UR's code, nor buddylist's. There is a point where a rewrite is less work and gives you best results.

I started from scratch, and wrote something that is actually well designed. I finished about 6 minutes ago. I am now testing the whole thing.

I am not sure about a migration path. User Relationnship has been abandoned for so long,..

Will keep you posted anyway.

Bye,

Merc.

toemaz’s picture

Hi Merc,

"I finished about 6 minutes ago"
You must be very confident ;-) My experience is that a module like UR/buddylist will never be finished, at least not for the maintainer who has to deal with all the feature requests, bug reports, ect.

Anyway, you made me curious.

mercmobily’s picture

Hi,

No module is ever "finished", really...!
I am actually a seasoned module maintainer. I maintain Drigg, a _huge_ Drupal module, and I know one thing or two about maintaining an issue queue :-D

Anyway if you're curious:

http://www.freesoftwaremagazine.com/friendlist.tgz

The only problem now is integration with other modules, which is not really something I am good at. See: views (yuck) or invite etc. Another missing feature for example is giving only node access to your fans, to people you are a fan of, and friends. Doing this with this module is _immensely_ simple (this is when you see that it's a good API). However, again, it's my weakness.

The idea is that having a good, functioning API will make all this easy to implement and possible... we'll see.

Merc.

mercmobily’s picture

Hi,

Toemaz: friendlist needs _exactly_ you right now!
You seem to be good at the things I am crap at :-D

Please have a look at the code and tell me what you think...

I will create a proper project page soon. I am still in the process of talking to the buddylist2 maintainer...

Merc.

toemaz’s picture

Merc, I must say, it does look promising. Lots of comments which makes it easy to understand.

Now, besides the fact that contrib modules should be written for this friendslist api to interface with other social networking modules in order to push adoption, I do see another challenge: what is the differentiator of this module compared to buddylist/buddylist2, friendslist, user relationschips, ect.

Often this question pops up in the social networking sites group and it is never really answered with a clear list of differences, use cases, pros, cons...

I presume you have been looking extensively into the code of user_relationships, friendslist and buddylist probably as well, otherwise you wouldn't write something from scratch. So you must have a clear idea why this new module is the best solution for 'your' use case. Perhaps we could start a wiki page in that group to make it clear to potential users what the differences are.

I'm sure if your use case matches with mine, I'll jump on board. Currently, I'm using the old buddylist1 module in production on a very heavy site. So one of the first things I could do is write a migration module from buddylist to this new one.

mercmobily’s picture

Hi,

the code of every other module is simply "unforgivable".
Drupal is great because everybody writes code. But as a software analyst/developer with 15 years of experience, I frankly want to puke sometimes.
But, just so that we know:

user_relationships: abandoned. Some of the ideas were promising. But, not enough was worth rescuing

buddylist: no division between API and UI. Not really usable

buddylist2: incomplete. Uses some of the features from buddylist and some from User Relationships, but the API design is simply not there.

friendslist: well designed. Clear, CLEAN API. Few, clear functions.

I am _immensely_ sleep deprived. I am testing the module right now, and fixing a couple of minor (and I mean really minor) glitches.

I do not have time nor energy to push for this module's adoption. I will publish it; developers will clearly see that it's better, and will build around it.

My big (huge) hope is that the Buddylist2 developer, who is a nice and reasonable guy, will join FriendList and add things like Views, User Access, etc. However, *I* will use and maintain FriendList.

Sorry, I don't mean to be too blunt, I am just immensely tired right now. And I am tired of seeing Drupal with no real friends API. Hopefully, a good sleep will fix the first problem, and my modue will fix the second one.

Merc.

alex.k’s picture

Assigned: prfctns6@gmail.com » alex.k
Status: Active » Fixed

This has been in the API for a while now. Simply add 'count' => TRUE to the second argument of user_relationships_load(). For example,

$count = user_relationships_load(array("between" => array($uid1, $uid2), "approved" => 1), array("count" => TRUE));

will return the number of established relationships between two users.

global $user;
$count = user_relationships_load(array("user" => $user->uid, "approved" => 1), array("count" => TRUE));

will give you the number of relationships you have with other users. See docs for user_relationships_load() for more info.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.