Class: Sipity::Repository

Inherits:
Object
  • Object
show all
Includes:
Commands, Queries
Defined in:
app/repositories/sipity/repository.rb

Overview

Note:

Yes I am using module mixins. Yes there are lots of methods in this class. Each of the mixins are tested in isolation. It is possible that there could be method collisions, but see the underlying specs for additional discussion and verification of method collisions.

Note:

Why is the Sipity::Services module and Sipity::Repository at the same module level? Right now, I believe that is a mistake. It makes sense to me that there will be multiple repository objects; After all some objects are going to come from another persistence service (i.e. DB or Fedora commons). I suspect there will be a negotiation layer to determine which persistence service to retrieve an entity from. That is to say if you want to edit an object ingested into Fedora you might request the object from Fedora, then request the object from a DB and layer the DB values on top of the Fedora values.

Defines and exposes the methods for interacting with the public API of the persistence layer.

Instance Method Summary collapse

Instance Method Details

#send_notification_for_entity_trigger(*_) ⇒ Object


29
30
31
# File 'app/repositories/sipity/repository.rb', line 29

def send_notification_for_entity_trigger(*_)
  fail NotImplementedError, "I want to expose this method, but I have layers of modules to consider"
end

#submit_etd_student_submission_trigger!Object


25
26
27
# File 'app/repositories/sipity/repository.rb', line 25

def submit_etd_student_submission_trigger!
  fail NotImplementedError, "I want to expose this method, but I have layers of modules to consider"
end

#submit_ingest_etdObject


33
34
35
# File 'app/repositories/sipity/repository.rb', line 33

def submit_ingest_etd
  fail NotImplementedError, "I want to expose this method, but I have layers of modules to consider"
end