niho / related Goto Github PK

RubyGems.org doesn't report a license for your gem. This is because it is not specified in the gemspec of your last release.

via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

Including a license in your gemspec is an easy way for rubygems.org and other tools to check how your gem is licensed. As you can imagine, scanning your repository for a LICENSE file or parsing the README, and then attempting to identify the license or licenses is much more difficult and more error prone. So, even for projects that already specify a license, including a license in your gemspec is a good practice. See, for example, how rubygems.org uses the gemspec to display the rails gem license.

There is even a License Finder gem to help companies/individuals ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough issue that even Bundler now generates gems with a default 'MIT' license.

I hope you'll consider specifying a license in your gemspec. If not, please just close the issue with a nice message. In either case, I'll follow up. Thanks for your time!

Appendix:

If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file), GitHub has created a license picker tool. Code without a license specified defaults to 'All rights reserved'-- denying others all rights to use of the code.
Here's a list of the license names I've found and their frequencies

p.s. In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :). See the previous link or my blog post about this project for more information.

Of course the underlying data structures don't become inconsistent for realz, since Redis prevents that. But since the #Related.redis.multi do lines in Relationship are commented out (I suppose to enable use of Distributed Redis connections, and with good reason) we can get relationships that are broken in the sense of being only one direction, for example.

Perhaps some kind of self healing would be a useful solution: Every time (or only some times) when an edge is traversed, Related checks the consistency of the edge (that it exists in all ordered and non-ordered sets it should), and fixes it if it is not.

Solving this kind of thing without distributed transactions is of course hard, but this kind of self healing is at least somewhat tried and true.

related currently triggers a few deprecation warnings, regarding the use of alias_method_chain. The three uses are here:

• https://github.com/sutajio/related/blob/v0.6.5/lib/related/node.rb#L174
• https://github.com/sutajio/related/blob/v0.6.5/lib/related/node.rb#L191
• https://github.com/sutajio/related/blob/v0.6.5/lib/related/node.rb#L208

I'm not entirely clear what the intent is behind those three lines. If you could shed some light on the intent, I'd be happy to send patches amending the code.

Make sure Related can be used in EventMachine based app servers like Goliath. Would also include trying to do as much fetching from Redis as possible in parallel.

The standard "redis" gem has support for EventMachine and fibers through "hiredis" and "em-synchrony". So shouldn't be very hard to implement.

My environment:

• ruby 1.9.3-p125
• rails 3.2.5
• devise 2.1
• related 0.6.3

When user model inherit Related::Node will result 'raise_no_devise_method_error!' as below

require 'related/follower'

class User < Related::Node
  include Related::Follower
end

Error message when start rails

/Users/joshchang/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/devise-2.1.0/lib/devise/rails/routes.rb:409:in 'raise_no_devise_method_error!': User does not respond to 'devise' method. This usually means you haven't loaded your ORM file or it's being loaded too late. To fix it, be sure to require 'devise/orm/YOUR_ORM' inside 'config/initializers/devise.rb' or before your application definition in 'config/application.rb' (RuntimeError)
from /Users/joshchang/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/devise-2.1.0/lib/devise/rails/routes.rb:210:in 'block in devise_for'
from /Users/joshchang/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/devise-2.1.0/lib/devise/rails/routes.rb:206:in 'each'
from /Users/joshchang/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/devise-2.1.0/lib/devise/rails/routes.rb:206:in 'devise_for'
from /Users/joshchang/repositories/tmp/foo/config/routes.rb:2 :in 'block in <top (required)>'
....

I try to add require 'devise/orm/active_record' in application.rb will result the other error.

/Users/joshchang/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/orm_adapter-0.0.7/lib/orm_adapter/adapters/active_record.rb:8 :in '< module:OrmAdapter >': uninitialized constant OrmAdapter::Base (NameError)
from /Users/joshchang/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/orm_adapter-0.0.7/lib/orm_adapter/adapters/active_record.rb:7 :in `<top (required)>'

Is there any solutions? Thanks.

Hello,

Pardom my ignorance, but I couldn't find a simple way to create bi-directional relationships between tags except creating two relationships and performing intersects on both incoming and outgoing.

I see that tagging pattern might have a value like following one, what do you think?

Last but no least, thank you for sharing Related with us.

Breath first should be more efficient in most cases than depth first, but is a bit trickier to implement correctly.

The relationship still exist in db after destroying node.

Thanks.

The intention is to allow you to use any ActiveModel-like storage backend you want to store the Node data. Currently Related stores a node as a Redis hash using Related::Entity which is a simple ActiveModel-like object-hash-mapper. The querying of the graph is largely decoupled from the storage layer and implemented in the Related::Node::QueryMethods module and Related::Node::Query class. Adding the same graph querying ability to any other compatible class should therefore be fairly trivial.

The idea is to create a simple implementation of a time-decaying popularity algorithm that can be used as a standard building block for many applications similar to how the Related::Follower module is useful.

The popularity algorithm should be time-decaying but preferably time-independent just like the Reddit algorithm. That makes it efficient to compute and easy to implement as a real-time stream processing data flow.

The ultimate implementation would be if we could also make the algorithm completely incremental and thus independent of the individual votes to compute the current score. That would mean that each time a new vote is cast a relative score is computed and the current score is incremented/decremented by the relative score. That way you don't have to fetch all previous votes and recalculate the absolute score every time a new vote is cast.

If no page is specified the results will be padded with null objects to fill up the per_page count. The page parameter should probably default to 1 if not specified to avoid this behavior.

The intention is for Related to be fairly easy to shard efficiently. To be able to shard in a useful way any system design needs to make trade-offs. Related relies heavily on the very efficient set operations that Redis provides, but with the obvious downside that those operations can't be efficiently supported in a sharded environment in a general way.

There are currently two proposed solutions to solving this:

1. Do set operations on the server side in Redis when possible (when the involved keys happen to exist on the same server) and emulate the set operation on the client side when it's not possible. For many applications like most social networks for example, this solution will be more than efficient enough. The drawback is of course that it will become less efficient the more shards you add and for networks with a very large number of relationships for each node (like a Twitter clone for example) it might not work very well at all at scale.
2. Store all node and relationship properties ("entities" in Related parlance) in a partitioned key space (using Redis::Distributed) which will allow you to store as many nodes and relationships as you want and scale infinitely to an unlimited number of servers. But store the set keys that defines the "links" between nodes on a single master server (or a replicated master-slave setup). In such a setup the only limitation will be how much data you can store on the master server, and since the sets are fairly compact compared to the entity properties in most applications, that should work fine most of the time. All set operation queries and graph traversal stuff will go to the master server and everything else will hit the sharded servers.

The initial attempt might be to implement both strategies to allow you to select the one that makes the most sense for your application.

Related currently uses MD5 hashes as keys for nodes and relationships which kind of forces us to use a distributed hash table (DHT) for sharding. It might be wise to consider using sequential 64-bit integers instead. Both for space efficiency reasons and for easier sharding because of their sequentially ordered nature.