I'm writing a forum system (in Ruby, using Sequel), and one of the requirements is for users to be able to "star" a thread, which is vaguely equivalent to "subscription" features most forums support. I'm unsure about how to store the starring in the database, and especially on how to query for starred/unstarred threads for a given user, or checking whether a thread is starred.
Any tips would be greatly appreciated, and if you happen to know your way around Sequel, an example model would be absolutely grand.
This is very simple to implement:
First your migration:
create_table(:subscriptions, ignore_index_errors: true) do
primary_key :id
column :created_at, 'timestamp with time zone'
foreign_key :user_id, :users, null: false, key: [:id], index: true, on_delete: :cascade
foreign_key :thread_id, :threads, null: false, key: [:id], index: true, on_delete: :cascade
end
Your Models:
app/models/subscription.rb
class Subscription < Sequel::Model
many_to_one :user
many_to_one :thread
end
app/models/user.rb
class User < Sequel::Model
one_to_many :subscriptions
many_to_many :subscribed_threads,
class: :Thread,
join_table: :subscriptions,
left_key: :user_id,
right_key: :thread_id
end
app/models/thread.rb
class Thread < Sequel::Model
one_to_many :subscriptions
many_to_many :subscribers,
class: :User,
join_table: :subscriptions,
left_key: :thread_id,
right_key: :user_id
end
Query as follows
# all threads a user is subscribed to
user.subscribed_threads
# all subscribers to a thread
thread.subscribers
# all subscriptions to a thread in the last 3 days
thread.subscriptions.where{created_at >= Date.today - 3}
I suggest also configuring the dataset associations plugin on all your models:
# Make all model subclasses create association methods for datasets
Sequel::Model.plugin :dataset_associations
You can then compose and chain queries through associations with conditions more conveniently:
# all new subscribers for a thread in the last 3 days who are moderators
thread.subscriptions.where{created_at >= Date.today - 3}.user.where(moderator: true)
There are some powerful filtering and querying possibilities:
http://sequel.jeremyevans.net/rdoc/files/doc/dataset_filtering_rdoc.html
http://sequel.jeremyevans.net/rdoc/files/doc/querying_rdoc.html
Related
how to say? I do not understand what the sequel documentation tries to tell me about associations in case of a two models linked over a foreign key in one model A being a primary key in the other in a may_to_one case.
I always thought: If it is many_to _one in one direction it has to be one_to_many in the other... but the sequel provides a confusing chapter meant to clarify the topic with in addition an example I cannot follow.
It says in
"Differences Between many_to_one and one_to_one"
If you want to setup a 1-1 relationship between two models, where the foreign > key in one table references the associated table directly, you have to use
many_to_one in one model, and one_to_one in the other model. How do
you know which to use in which model? The simplest way to remember is
that the model whose table has the foreign key uses many_to_one, and
the other model uses one_to_one"
And continues to provide this strange example:
# Database schema:
# artists albums
# :id <----\ :id
# :name \----- :artist_id
# :name
class Artist
one_to_one :album
end
class Album
many_to_one :artist
end
In albums I may find several rows pointing to same artist... why shouldn't the artist point back to all his/her albums?
The sequel docu is crazy hard to read in many cases but this chapter reads easy but makes no sense for me:(
Same issue for me.
require "logger"
require "sequel"
db = Sequel.connect "postgres://localhost/postgres", :logger => Logger.new(STDOUT)
db.drop_table :artists, :cascade => true if db.table_exists?(:artists)
db.create_table :artists do
primary_key :id
foreign_key :album_id, :albums
end
db.drop_table :albums, :cascade => true if db.table_exists?(:albums)
db.create_table :albums do
primary_key :id
foreign_key :artist_id, :artists
end
class Artist < Sequel::Model(db[:artists])
one_to_one :album
end
class Album < Sequel::Model(db[:albums])
one_to_one :artist
end
artist_1 = Artist.create
album_1 = Album.create
artist_1.update :album => album_1
album_1.reload
puts album_1.artist.nil?
artist_2 = Artist.create
album_2 = Album.create
album_2.update :artist => artist_2
artist_2.reload
puts artist_2.album.nil?
We can fix this example by replacing any of one_to_one into many_to_one.
class Album
many_to_one :artist
end
In this case artist.album_id won't be used.
class Artist
many_to_one :albums
end
In this case album.artist_id won't be used.
The problem is that method names one_to_one and many_to_one were selected by underlying sequel logic and they are not user friendly.
You can create user friendly aliases for these methods. I prefer just to use it with comments. For example:
db.create_table :artists do
primary_key :id
foreign_key :album_id, :albums
end
db.create_table :albums do
primary_key :id
end
class Artist < Sequel::Model(db[:artists])
many_to_one :album # I have album_id foreign key
end
class Album < Sequel::Model(db[:albums])
one_to_one :artist # I don't have artist_id foreign key
end
I have two models, which associate with each other through a has_and_belongs_to_many relationship.
class Band < ActiveRecord::Base
has_and_belongs_to_many :stages, association_foreign_key: :stage_number
end
class Stage < ActiveRecord::Base
has_and_belongs_to_many :bands
end
Assume both tables have an id field, and that stage has a stage_name field.
They're related to each other through a table called bands_stages, with a schema that looks similar to this:
create_table :bands_stages, id: false do |t|
t.integer :band_id
t.integer :stage_number
end
My intention is to use Rails Admin to allow us to modify certain fields on the Stage, but every time that runs, I get an SQL error doing so:
column stages.id does not exist
It seems that Rails Admin is picking the wrong column by default to join on. How would I inform Rails Admin that I want it to join on a column that actually exists in my join table?
Note that I can't actually make use of the ID in the stages table. The intention is that only ten stages exist at any given time, denoted by their stage number, but every band can visit each stage. Since an ID would automatically increment, it seems to be safer and more explicit to its intent to leverage the more concrete :stage_number field instead.
I'm sure that it's not a problem of rails admin but habtm association.
To make habtm use the right column in sql primary key must be specified for stage model and foreign key for association.
And it is the only way to make it works right.
class Stage < ActiveRecord::Base
self.primary_key = "stage_number"
has_and_belongs_to_many :bands, foreign_key: :stage_number
end
But I think the best way is to use joint model and has_many/belongs_to because for has_many/belongs_to it's possible to set any column to be used as primary key via :primary_key option.
class BandStageLink < ActiveRecord::Base
self.table_name = "bands_stages"
belongs_to :band
belongs_to :stage, foreign_key: :stage_number, primary_key: :stage_number
end
class Band < ActiveRecord::Base
has_many :band_stage_links
has_many :stages, through: :band_stage_links, foreign_key: :stage_number
end
class Stage < ActiveRecord::Base
has_many :band_stage_links, primary_key: :stage_number, foreign_key: :stage_number
has_many :bands, through: :band_stage_links
end
Update: Note that in this case there is still no need to specify any primary keys for stage table. For instance my migration is:
class CreateStageBandTables < ActiveRecord::Migration
def change
create_table :bands_stages, id: false do |t|
t.integer :band_id
t.integer :stage_number
end
create_table :bands do |t|
t.string :name
end
create_table :stages, id: false do |t|
t.integer :stage_number
t.string :name
end
end
end
I tested both cases for rails 4.2.5 and everything works just fine.
Edit - I did mis-understand the primary key bit, I think the desire was to tell Rails to use different attribute as PK, which should be less problematic than re-purposing the auto-increment-by-default PK ID. In that case, the Stage model should include self.primary_key = "stage_number", and the rest of the details at the bottom of this answer relating to HABTM alongside that. Of course has-many-through would still be my preferred solution here.
I think there's a bigger problem with the models and approach, than Rails Admin.
If I understand what you're trying to do, then you'd also need to turn off auto-increment for the primary key in stages table, to hold arbitrary numbers (representing stage numbers) as primary key IDs. It could end badly very quickly, so I'd advise against it.
If the data is genuinely static (10 stages ever), you could even keep it as a constant in the Band model and scrap Stage completely (unless there's more there), e.g.
class Band < ActiveRecord::Base
POSSIBLE_STAGES = [1, 2, ...]
validates :stage, inclusion: { in: POSSIBLE_STAGES, message: "%{value} is not a stage we know of!" }
end
For a table-based approach, I would suggest has-many-through, it'll save you a lot of pain in the future (even if you don't need additional attributes on the join table, things like nested forms are a little easier to work with than in HABTM). Something like this:
class Band < ActiveRecord::Base
has_many :events
has_many :stages, through :events
# band details go into this model
end
class Event < ActiveRecord::Base
belongs_to :band
belongs_to :stage
# you could later add attributes here, such as date/time of event, used_capacity, attendee rating, and
# even validations such as no more than X bands on any given stage at the same time etc.
end
class Stage < ActiveRecord::Base
has_many :events
has_many :bands, through :events
# stage number/details go into this model
end
The migration for that could look something like this:
create_table :bands do |t|
t.string :bandname
# whatever else
end
create_table :events do |t|
t.belongs_to :band
t.belongs_to :stage
# you could add attributes here as well, e.g. t.integer :used_capacity
end
create_table :stages do |t|
t.integer :number
t.integer :total_capacity
# whatever else
end
As you can see primary key IDs are not touched here at all, and I would always avoid storing business data in Rails' and databases' plumbing of any sort (which is what I consider IDs to be, they're there to ensure relation/integrity of the data in a relational database, as well as nice and consistent mapping to ActiveRecord - all business data should be beside that, in actual attributes, not plumbing used to connect models).
If you still want HABTM and re-purposing of primary ID, then I think Stage should include a foreign_key statement to "advertise" itself to the bands_stages join table as having a custom key name (in bands_stages only), while keeping the association_foreign_key on the Band end to show what you want to query in the join table to reach the other side. The stages table would still utilise id though as its primary key, you'd just want to turn off auto-increment with something like t.integer :id, :options => 'PRIMARY KEY' (might be dependent on the database flavour - and again, I would advise against this).
Your models would look like this:
class Band < ActiveRecord::Base
has_and_belongs_to_many :stages, association_foreign_key: "stage_number"
end
class Stage < ActiveRecord::Base
has_and_belongs_to_many :bands, foreign_key: "stage_number"
end
The connection between bands and bands_stages would be bands.id = bands_stages.band_id, for which many bands_stages.stage_number would be found, and each would be connected to stage via bands_stages.stage_number = stages.id (where stages.id has been re-purposed to represent business data at a likely future peril).
Change the association_foreign_key value to be a string instead of symbol.
class Band < ActiveRecord::Base
has_and_belongs_to_many :stages, association_foreign_key: 'stage_number'
end
class Stage < ActiveRecord::Base
has_and_belongs_to_many :bands, foreign_key: 'stage_number'
end
I want to store extra data in a many-to-many relationship, similar to this Django example, in Sequel and Postgres.
In my example, each person has a place they work, and what hours they work there. Each person can work different hours at the same place. For example...
Joe works at The Bar Mon, Wed & Fri 9-5pm.
Joe also works at The Bar Saturday noon-midnight.
Joe works at Some Pub Sunday 12-5.
Joe started working at The Bar 2013-12-07
Joe started working at Some Pub 2014-12-23
I'm wondering how to set up the tables and models to make this as not awkward as possible. Currently I have a schema like this.
create_table(:people) do
primary_key :id
String :name
end
create_table(:works) do
primary_key :id
String :name
end
create_table(:employments) do
primary_key :id
foreign_key :work_id, :work, null: false,
foreign_key :person_id, :people, null: false,
Date :started
end
create_table(:hours) do
primary_key :id
foreign_key :employment_id, :employments, null: false
String :dow, null: false,
Time :start, null: false, only_time: true
Time :end, null: false, only_time: true
end
How should I create the model associations to join it all together? Ideally I would like to be able to say something like...
joes_hours_at_some_pub = joe.employment("Some Pub").hours
...without having to go through the intermediate join table.
Sequel's advanced association doc has an example of this. Define an Employment model and use :join_table to create a relationship through it.
class Person < Sequel::Model
one_to_many :employments,
many_to_many :works, join_table: :employments
# This allows joe.employment(work).hours
def employment(work)
employments_dataset.where(work_id: work.id)
end
end
class Work < Sequel::Model
one_to_many :employments,
many_to_many :people, join_table: :employments
end
class Employment < Sequel::Model
many_to_one :person
many_to_one :work
one_to_many :hours
end
class Hours < Sequel::Model
many_to_one :practice
end
I am creating a simple Sinatra app, using Sequel for my ORM.
Most of the data revolves around users and events where:
An event can have many users, one of which is the "owner".
Users can have many events, one or many of which they "own".
Here is a simplified version of my schema/model definitions:
class User < Sequel::Model(:users)
many_to_many :events
one_to_one :event
end
class Event < Sequel::Model(:events)
many_to_many :users
many_to_one :user
end
# provides a link between users and events
# e.g. event.users or user.events
# I am unsure how necessary this is :)
db.create_table :events_users do
primay_key :id
foreign_key :event_id, :events
foreign_key :user_id, :users
end
This allows me to get the users attached to an event, or the events that a user is attached to, but I am struggling to express the "ownership" of an event. It seems like the following pseudocode would work:
my_user = User.all.first
owned_events = Event.where(user_id = my_user.user_id)
That leads to two questions:
Does the current way i'm using assocations make sense?
How do I express ownership of an event in terms of Sequel's association model?
Maybe something like this:
class Event
many_to_one :owner, :class=>:User
many_to_many :users
end
class User
one_to_many :owned_events, :class=>:Event, :key=>:owner_id
many_to_many :events
end
You'll need to add owned_id field in events table.
Usage:
user = User.all.first
event = Event.new(:title => 'New Event')
events.add_owner(user)
event.save
another_user = User.create(:name => 'Jack')
event.add_user(another_user)
I have a data structure in which Topics have subtopics, which again have subtopics, continuing down from the original Topic about six levels. Each of these topics has multiple subtopics.
I'm looking for a way to traverse this data and bring back data affiliated from each of the subtopics... as if pulling the data I want "downstream".
For example Given a topic structure:
Harry_Potter > Characters > Slitherin_House.videos
(Assuming that slitherin house has subtopics for each of the members, Malfoy, Crabbe, etc. ) I want the videos for each of the members to appear in the video lists for Slitherin_House, Characters, and Harry_Potter (each of the ancestors).
I've been looking around and stumbled across Ancestry and Acts As Tree and read through the code and tried my hand at using them, but they seem more oriented around the ancestor side of things, as opposed to accessing and pulling data from the children.
I also have tried my hand at using the associations
has_many :through, and has_and_belongs_to_many
but have been unsuccessful in my attempts to create a working traversal system. And can't seem to complete wrap my head around how to do this.
Does anyone have any ideas or suggestions on what to do given such a predicament? Or know of gems which provide for any such functionality?
Relationship class & model: (as it should flow like a stream)
class CreateStreams < ActiveRecord::Migration
def change
create_table :streams do |t|
t.integer :downstream_id
t.integer :upstream_id
t.timestamps
end
add_index :streams, :downstream_id
add_index :streams, :upstream_id
add_index :streams, [:downstream_id, :upstream_id], unique: true
end
end
# == Schema Information
#
# Table name: streams
#
# id :integer not null, primary key
# downstream_id :integer
# upstream_id :integer
# created_at :datetime not null
# updated_at :datetime not null
#
class Stream < ActiveRecord::Base
attr_accessible :downstream_id
belongs_to :subsidiary, class_name: "Topic"
belongs_to :tributary, class_name: "Topic"
validates :downstream_id, presence: true
validates :upstream_id, presence: true
end
Topic Model
# == Schema Information
#
# Table name: topics
#
# id :integer not null, primary key
# name :string(255)
# created_at :datetime not null
# updated_at :datetime not null
# slug :string(255)
# wiki :string(255)
# summary :string(255)
class Topic < ActiveRecord::Base
extend FriendlyId
attr_accessible :name, :wiki, :summary
has_many :streams, foreign_key: "downstream_id", dependent: :destroy
has_many :tributaries, through: :streams, source: :tributary
has_many :reverse_streams, foreign_key: "upstream_id",
class_name: "Stream",
dependent: :destroy
has_many :subsidiaries, :through => :reverse_streams, source: :subsidiary
friendly_id :name, use: :slugged
validates :name, presence: true, length: { maximum: 50 },
uniqueness: { case_sensitive: false }
def downstream?(other_topic)
streams.find_by_downstream_id(other_topic.id)
end
def flow!(other_topic)
streams.create!(downstream_id: other_topic.id)
end
def dam!(other_topic)
streams.find_by_downstream_id(other_topic.id).destroy
end
end
Note: I also want to be able to assign a subtopic, multiple parents. So that characters could potentially get put underneath of "Actors" as well for example.
if you want to set this up in a simple way i'd go for a recursive relation. This means a topic can belong to another topic (nested)
The database model of the topic would look like:
Topic
id
topic_id
title
the model would then be:
class Topic < ActiveRecord::Base
belongs_to :topic
has_many :topics
end
Now if you have a topic. you can access its parents by doing .topic and its childs with .topics. A Topic with no parent is a toplevel one and a Topic with no childs is a end node.