Updating many-to-many relationships

daviddavis · January 28, 2014, 8:01pm

So there seems to be a divergence in how Foreman and Katello handle many-to-many relationships. To give a couple examples of these, one would be architectures which have and belong to many OSes in Foreman. In Katello, content views has and belongs to many repositories There 2-3 options for updating these relationships:

Send in operating_system_ids on PUT /architecture/2
Have add_operating_systems and remove_operating_systems actions that take ids
Both 2 and 3

Foreman looks like it mostly supports 1 while Katello has a combination in its v2 api of 1 and 2 (but not 3). I can see advantages to all: 1 is simpler while 2 would maybe be easier to use for the user. 3 seems like a good option but would be the most work.

Thoughts?

David

Walden_Raines · January 28, 2014, 8:20pm

Even though I just followed an existing pattern and implemented a new occurrence of #2, I prefer #1 as it is more RESTful.

Cheers,
Walden

···

----- Original Message ----- From: "David Davis" To: "foreman-dev" Sent: Tuesday, January 28, 2014 3:01:29 PM Subject: [foreman-dev] Updating many-to-many relationships

So there seems to be a divergence in how Foreman and Katello handle many-to-many relationships. To give a couple examples of these, one would be architectures which have and belong to many OSes in Foreman. In Katello, content views has and belongs to many repositories There 2-3 options for updating these relationships:

Send in operating_system_ids on PUT /architecture/2
Have add_operating_systems and remove_operating_systems actions that take ids
Both 2 and 3

Foreman looks like it mostly supports 1 while Katello has a combination in its v2 api of 1 and 2 (but not 3). I can see advantages to all: 1 is simpler while 2 would maybe be easier to use for the user. 3 seems like a good option but would be the most work.

Thoughts?

David

–
You received this message because you are subscribed to the Google Groups “foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Joseph_Magen · January 29, 2014, 7:59am

There's a 3rd option and that is to PUT the JSON response from GET

GET api/v2/operatingsystems/24

Part of the response includes architectures as a child-node

{
"id": 24,
"name": "CentOs",
"architectures": [
{
"name": "x86_64",
"id": 1
}
]
}

PUT api/v2/operatingsystems/24

And ad another OS in the JSON data

{
"id": 24,
"name": "CentOs",
"architectures": [
{
"name": "x86_64",
"id": 1
},
{
"name": "i386",
"id": 2
}
]
}

Actually, most of the JSON data above is unnecessary. I can just pass in the relationship node with a collection of ids

PUT api/v2/operatingsystems/24

{
"architectures": [
{
"id": 1
},
{
"id": 2
}
]
}

Note that you can NOT add or remove a SINGLE id as in your option #2. I agree with Walden not to implement this.

Below, this example CREATES a record in has_and_belongs_to_many relationship table

PUT api/v2/operatingsystems/24

{
"architectures": [
{
"id": 1
},
{
"id": 2
}
},
{
"id": 3
}
]
}

This DELETES a record in has_and_belongs_to_many relationship table

PUT api/v2/operatingsystems/24

{
"architectures": [
{
"id": 1
}
]
}

Note that this should work with every has_many or has_and_belongs_to_many relationship even if nested routes or child nodes may not appear for in RABL templates for all objects.

In summary, Foreman supports
#1) Array on attribute operatingsystem_ids on PUT /architecture/2

{
"operatingsystem_ids": [24,25,26]
}

#3) Array on child not operatingsystems PUT /architecture/2

{
"operatingsystems": [{"id": 24},{"id": 25},{"id": 26}]
}

David, I hope this helps. I agree that the documentation needs to be better. Can you take the initiative on updating the docs once we reach a final decision.

Thanks,

Joseph

···

----- Original Message ----- > From: "Walden Raines" > To: foreman-dev@googlegroups.com > Sent: Tuesday, January 28, 2014 10:20:15 PM > Subject: Re: [foreman-dev] Updating many-to-many relationships > > Even though I just followed an existing pattern and implemented a new > occurrence of #2, I prefer #1 as it is more RESTful. > > Cheers, > Walden > > ----- Original Message ----- > From: "David Davis" > To: "foreman-dev" > Sent: Tuesday, January 28, 2014 3:01:29 PM > Subject: [foreman-dev] Updating many-to-many relationships > > So there seems to be a divergence in how Foreman and Katello handle > many-to-many relationships. To give a couple examples of these, one would be > architectures which have and belong to many OSes in Foreman. In Katello, > content views has and belongs to many repositories There 2-3 options for > updating these relationships: > > 1. Send in operating_system_ids on PUT /architecture/2 > 2. Have add_operating_systems and remove_operating_systems actions that take > ids > 3. Both 2 and 3 > > Foreman looks like it mostly supports 1 while Katello has a combination in > its v2 api of 1 and 2 (but not 3). I can see advantages to all: 1 is simpler > while 2 would maybe be easier to use for the user. 3 seems like a good > option but would be the most work. > > Thoughts? > > David > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. >

daviddavis · January 29, 2014, 1:13pm

Joseph,

I'll update the docs when we reach a decision. Question though: how did you all add support for the third option you outlined? Does it comes with Rails?

David

···

----- Original Message ----- > From: "Joseph Magen" > To: foreman-dev@googlegroups.com > Sent: Wednesday, January 29, 2014 2:59:08 AM > Subject: Re: [foreman-dev] Updating many-to-many relationships > > There's a 3rd option and that is to PUT the JSON response from GET > > GET api/v2/operatingsystems/24 > > Part of the response includes architectures as a child-node > > { > "id": 24, > "name": "CentOs", > "architectures": [ > { > "name": "x86_64", > "id": 1 > } > ] > } > > PUT api/v2/operatingsystems/24 > > And ad another OS in the JSON data > > { > "id": 24, > "name": "CentOs", > "architectures": [ > { > "name": "x86_64", > "id": 1 > }, > { > "name": "i386", > "id": 2 > } > ] > } > > Actually, most of the JSON data above is unnecessary. I can just pass in the > relationship node with a collection of ids > > PUT api/v2/operatingsystems/24 > > { > "architectures": [ > { > "id": 1 > }, > { > "id": 2 > } > ] > } > > Note that you can NOT add or remove a SINGLE id as in your option #2. I > agree with Walden not to implement this. > > Below, this example CREATES a record in has_and_belongs_to_many relationship > table > > PUT api/v2/operatingsystems/24 > > { > "architectures": [ > { > "id": 1 > }, > { > "id": 2 > } > }, > { > "id": 3 > } > ] > } > > This DELETES a record in has_and_belongs_to_many relationship table > > PUT api/v2/operatingsystems/24 > > { > "architectures": [ > { > "id": 1 > } > ] > } > > > Note that this should work with every has_many or has_and_belongs_to_many > relationship even if nested routes or child nodes may not appear for in RABL > templates for all objects. > > > In summary, Foreman supports > #1) Array on attribute operatingsystem_ids on PUT /architecture/2 > > { > "operatingsystem_ids": [24,25,26] > } > > #3) Array on child not operatingsystems PUT /architecture/2 > > { > "operatingsystems": [{"id": 24},{"id": 25},{"id": 26}] > } > > David, I hope this helps. I agree that the documentation needs to be better. > Can you take the initiative on updating the docs once we reach a final > decision. > > Thanks, > > Joseph > > > > > > > > > > > > ----- Original Message ----- > > From: "Walden Raines" > > To: foreman-dev@googlegroups.com > > Sent: Tuesday, January 28, 2014 10:20:15 PM > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > Even though I just followed an existing pattern and implemented a new > > occurrence of #2, I prefer #1 as it is more RESTful. > > > > Cheers, > > Walden > > > > ----- Original Message ----- > > From: "David Davis" > > To: "foreman-dev" > > Sent: Tuesday, January 28, 2014 3:01:29 PM > > Subject: [foreman-dev] Updating many-to-many relationships > > > > So there seems to be a divergence in how Foreman and Katello handle > > many-to-many relationships. To give a couple examples of these, one would > > be > > architectures which have and belong to many OSes in Foreman. In Katello, > > content views has and belongs to many repositories There 2-3 options for > > updating these relationships: > > > > 1. Send in operating_system_ids on PUT /architecture/2 > > 2. Have add_operating_systems and remove_operating_systems actions that > > take > > ids > > 3. Both 2 and 3 > > > > Foreman looks like it mostly supports 1 while Katello has a combination in > > its v2 api of 1 and 2 (but not 3). I can see advantages to all: 1 is > > simpler > > while 2 would maybe be easier to use for the user. 3 seems like a good > > option but would be the most work. > > > > Thoughts? > > > > David > > > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-dev+unsubscribe@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-dev+unsubscribe@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. >

Bryan_Kearney · January 29, 2014, 3:48pm

What about a

PUT api/v2/operatingsystems/24/architectures

??

– bk

···

On 01/29/2014 02:59 AM, Joseph Magen wrote: > There's a 3rd option and that is to PUT the JSON response from GET > > GET api/v2/operatingsystems/24 > > Part of the response includes architectures as a child-node > > { > "id": 24, > "name": "CentOs", > "architectures": [ > { > "name": "x86_64", > "id": 1 > } > ] > } > > PUT api/v2/operatingsystems/24 > > And ad another OS in the JSON data > > { > "id": 24, > "name": "CentOs", > "architectures": [ > { > "name": "x86_64", > "id": 1 > }, > { > "name": "i386", > "id": 2 > } > ] > } > > Actually, most of the JSON data above is unnecessary. I can just pass in the relationship node with a collection of ids > > PUT api/v2/operatingsystems/24 > > { > "architectures": [ > { > "id": 1 > }, > { > "id": 2 > } > ] > } > > Note that you can NOT add or remove a SINGLE id as in your option #2. I agree with Walden not to implement this. > > Below, this example CREATES a record in has_and_belongs_to_many relationship table > > PUT api/v2/operatingsystems/24 > > { > "architectures": [ > { > "id": 1 > }, > { > "id": 2 > } > }, > { > "id": 3 > } > ] > } > > This DELETES a record in has_and_belongs_to_many relationship table > > PUT api/v2/operatingsystems/24 > > { > "architectures": [ > { > "id": 1 > } > ] > } > > > Note that this should work with every has_many or has_and_belongs_to_many relationship even if nested routes or child nodes may not appear for in RABL templates for all objects. > > > In summary, Foreman supports > #1) Array on attribute operatingsystem_ids on PUT /architecture/2 > > { > "operatingsystem_ids": [24,25,26] > } > > #3) Array on child not operatingsystems PUT /architecture/2 > > { > "operatingsystems": [{"id": 24},{"id": 25},{"id": 26}] > } > > David, I hope this helps. I agree that the documentation needs to be better. Can you take the initiative on updating the docs once we reach a final decision. > > Thanks, > > Joseph > > > > > > > > > > > > ----- Original Message ----- >> From: "Walden Raines" >> To: foreman-dev@googlegroups.com >> Sent: Tuesday, January 28, 2014 10:20:15 PM >> Subject: Re: [foreman-dev] Updating many-to-many relationships >> >> Even though I just followed an existing pattern and implemented a new >> occurrence of #2, I prefer #1 as it is more RESTful. >> >> Cheers, >> Walden >> >> ----- Original Message ----- >> From: "David Davis" >> To: "foreman-dev" >> Sent: Tuesday, January 28, 2014 3:01:29 PM >> Subject: [foreman-dev] Updating many-to-many relationships >> >> So there seems to be a divergence in how Foreman and Katello handle >> many-to-many relationships. To give a couple examples of these, one would be >> architectures which have and belong to many OSes in Foreman. In Katello, >> content views has and belongs to many repositories There 2-3 options for >> updating these relationships: >> >> 1. Send in operating_system_ids on PUT /architecture/2 >> 2. Have add_operating_systems and remove_operating_systems actions that take >> ids >> 3. Both 2 and 3 >> >> Foreman looks like it mostly supports 1 while Katello has a combination in >> its v2 api of 1 and 2 (but not 3). I can see advantages to all: 1 is simpler >> while 2 would maybe be easier to use for the user. 3 seems like a good >> option but would be the most work. >> >> Thoughts? >> >> David >> >> -- >> You received this message because you are subscribed to the Google Groups >> "foreman-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to foreman-dev+unsubscribe@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "foreman-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to foreman-dev+unsubscribe@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >

Aaron_Stone · January 29, 2014, 4:12pm

Option #3 is great when you want to rewrite everything, and terrible in all
other cases. Please allow the minimum edit. GET-modify-PUT has two big
problems: race conditions between editors, and large message size. If
you're trying to edit thingy x with parameter y, an URL to x is very
helpful for being specific and atomic.

···

On Wed, Jan 29, 2014 at 7:48 AM, Bryan Kearney wrote:

What about a

PUT api/v2/operatingsystems/24/architectures

??

– bk

On 01/29/2014 02:59 AM, Joseph Magen wrote:

There’s a 3rd option and that is to PUT the JSON response from GET

GET api/v2/operatingsystems/24

Part of the response includes architectures as a child-node

{
“id”: 24,
“name”: “CentOs”,
“architectures”: [
{
“name”: “x86_64”,
“id”: 1
}
]
}

PUT api/v2/operatingsystems/24

And ad another OS in the JSON data

{
“id”: 24,
“name”: “CentOs”,
“architectures”: [
{
“name”: “x86_64”,
“id”: 1
},
{
“name”: “i386”,
“id”: 2
}
]
}

Actually, most of the JSON data above is unnecessary. I can just pass in
the relationship node with a collection of ids

PUT api/v2/operatingsystems/24

{
“architectures”: [
{
“id”: 1
},
{
“id”: 2
}
]
}

Note that you can NOT add or remove a SINGLE id as in your option #2. I
agree with Walden not to implement this.

Below, this example CREATES a record in has_and_belongs_to_many
relationship table

PUT api/v2/operatingsystems/24

{
“architectures”: [
{
“id”: 1
},
{
“id”: 2
}
},
{
“id”: 3
}
]
}

This DELETES a record in has_and_belongs_to_many relationship table

PUT api/v2/operatingsystems/24

{
“architectures”: [
{
“id”: 1
}
]
}

Note that this should work with every has_many or has_and_belongs_to_many
relationship even if nested routes or child nodes may not appear for in
RABL templates for all objects.

In summary, Foreman supports
#1) Array on attribute operatingsystem_ids on PUT /architecture/2

{
“operatingsystem_ids”: [24,25,26]
}

#3) Array on child not operatingsystems PUT /architecture/2

{
“operatingsystems”: [{“id”: 24},{“id”: 25},{“id”: 26}]
}

David, I hope this helps. I agree that the documentation needs to be
better. Can you take the initiative on updating the docs once we reach a
final decision.

Thanks,

Joseph

----- Original Message -----

From: “Walden Raines” walden@redhat.com
To: foreman-dev@googlegroups.com
Sent: Tuesday, January 28, 2014 10:20:15 PM
Subject: Re: [foreman-dev] Updating many-to-many relationships

Even though I just followed an existing pattern and implemented a new
occurrence of #2, I prefer #1 as it is more RESTful.

Cheers,
Walden

----- Original Message -----
From: “David Davis” daviddavis@redhat.com
To: “foreman-dev” foreman-dev@googlegroups.com
Sent: Tuesday, January 28, 2014 3:01:29 PM
Subject: [foreman-dev] Updating many-to-many relationships

So there seems to be a divergence in how Foreman and Katello handle
many-to-many relationships. To give a couple examples of these, one
would be
architectures which have and belong to many OSes in Foreman. In Katello,
content views has and belongs to many repositories There 2-3 options for
updating these relationships:

Send in operating_system_ids on PUT /architecture/2

Have add_operating_systems and remove_operating_systems actions that
take
ids

Both 2 and 3

Foreman looks like it mostly supports 1 while Katello has a combination
in
its v2 api of 1 and 2 (but not 3). I can see advantages to all: 1 is
simpler
while 2 would maybe be easier to use for the user. 3 seems like a good
option but would be the most work.

Thoughts?

David

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Joseph_Magen · January 29, 2014, 1:22pm

Hi David,

Rails comes out-of-the-box with support for column_names_ids = [1,2,3,4]

Option #3 I created a before_filter in api/v2/base_controller.rb

github.com

isratrade/foreman/blob/inherit_loc/app/controllers/api/v2/base_controller.rb#L11


module Api
module V2
  class BaseController < Api::BaseController
    include Api::Version2


    resource_description do
      api_version "v2"
      app_info "Foreman v2 is currently in development and is not the default version. You may use v2 by either passing 'version=2' in the Accept Header or entering api/v2/ in the URL."
    end


    before_filter :setup_has_many_params, :only => [:create, :update]
    layout 'api/v2/layouts/index_layout', :only => :index


    helper_method :root_node_name, :metadata_total, :metadata_subtotal, :metadata_search,
                  :metadata_order, :metadata_by, :metadata_page, :metadata_per_page


    def root_node_name
      @root_node_name ||= if Rabl.configuration.use_controller_name_as_json_root
                            controller_name.split('/').last
                          elsif params['root_name'].present?
                            params['root_name']

Basically, I manipulated the input to convert from an array of JSON objects to get attribute :column_names_ids = [1,2,3,4] which is what Rails likes in the standard update_attributes method
Note, column_names_names = ["name1", "name2"] also works.

Joseph

···

----- Original Message ----- > From: "David Davis" > To: foreman-dev@googlegroups.com > Sent: Wednesday, January 29, 2014 3:13:57 PM > Subject: Re: [foreman-dev] Updating many-to-many relationships > > Joseph, > > I'll update the docs when we reach a decision. Question though: how did you > all add support for the third option you outlined? Does it comes with Rails? > > David > > ----- Original Message ----- > > From: "Joseph Magen" > > To: foreman-dev@googlegroups.com > > Sent: Wednesday, January 29, 2014 2:59:08 AM > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > There's a 3rd option and that is to PUT the JSON response from GET > > > > GET api/v2/operatingsystems/24 > > > > Part of the response includes architectures as a child-node > > > > { > > "id": 24, > > "name": "CentOs", > > "architectures": [ > > { > > "name": "x86_64", > > "id": 1 > > } > > ] > > } > > > > PUT api/v2/operatingsystems/24 > > > > And ad another OS in the JSON data > > > > { > > "id": 24, > > "name": "CentOs", > > "architectures": [ > > { > > "name": "x86_64", > > "id": 1 > > }, > > { > > "name": "i386", > > "id": 2 > > } > > ] > > } > > > > Actually, most of the JSON data above is unnecessary. I can just pass in > > the > > relationship node with a collection of ids > > > > PUT api/v2/operatingsystems/24 > > > > { > > "architectures": [ > > { > > "id": 1 > > }, > > { > > "id": 2 > > } > > ] > > } > > > > Note that you can NOT add or remove a SINGLE id as in your option #2. I > > agree with Walden not to implement this. > > > > Below, this example CREATES a record in has_and_belongs_to_many > > relationship > > table > > > > PUT api/v2/operatingsystems/24 > > > > { > > "architectures": [ > > { > > "id": 1 > > }, > > { > > "id": 2 > > } > > }, > > { > > "id": 3 > > } > > ] > > } > > > > This DELETES a record in has_and_belongs_to_many relationship table > > > > PUT api/v2/operatingsystems/24 > > > > { > > "architectures": [ > > { > > "id": 1 > > } > > ] > > } > > > > > > Note that this should work with every has_many or has_and_belongs_to_many > > relationship even if nested routes or child nodes may not appear for in > > RABL > > templates for all objects. > > > > > > In summary, Foreman supports > > #1) Array on attribute operatingsystem_ids on PUT /architecture/2 > > > > { > > "operatingsystem_ids": [24,25,26] > > } > > > > #3) Array on child not operatingsystems PUT /architecture/2 > > > > { > > "operatingsystems": [{"id": 24},{"id": 25},{"id": 26}] > > } > > > > David, I hope this helps. I agree that the documentation needs to be > > better. > > Can you take the initiative on updating the docs once we reach a final > > decision. > > > > Thanks, > > > > Joseph > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > From: "Walden Raines" > > > To: foreman-dev@googlegroups.com > > > Sent: Tuesday, January 28, 2014 10:20:15 PM > > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > > > Even though I just followed an existing pattern and implemented a new > > > occurrence of #2, I prefer #1 as it is more RESTful. > > > > > > Cheers, > > > Walden > > > > > > ----- Original Message ----- > > > From: "David Davis" > > > To: "foreman-dev" > > > Sent: Tuesday, January 28, 2014 3:01:29 PM > > > Subject: [foreman-dev] Updating many-to-many relationships > > > > > > So there seems to be a divergence in how Foreman and Katello handle > > > many-to-many relationships. To give a couple examples of these, one would > > > be > > > architectures which have and belong to many OSes in Foreman. In Katello, > > > content views has and belongs to many repositories There 2-3 options for > > > updating these relationships: > > > > > > 1. Send in operating_system_ids on PUT /architecture/2 > > > 2. Have add_operating_systems and remove_operating_systems actions that > > > take > > > ids > > > 3. Both 2 and 3 > > > > > > Foreman looks like it mostly supports 1 while Katello has a combination > > > in > > > its v2 api of 1 and 2 (but not 3). I can see advantages to all: 1 is > > > simpler > > > while 2 would maybe be easier to use for the user. 3 seems like a good > > > option but would be the most work. > > > > > > Thoughts? > > > > > > David > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "foreman-dev" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "foreman-dev" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-dev+unsubscribe@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. >

Joseph_Magen · January 30, 2014, 7:42am

To be specific and atomic, then you need to treat the many-to-many relation as its own resource. This is not the case with our example

PUT api/v2/operatingsystems/24

which update all the attributes AND associations for resource operating system #24

The RESTful way to only add or delete an association (similar to what we did for host_classes and hostgroup_classes) is this below: (Note that BOTH the architecture id and operating system id's already exist)

Create a new association
POST api/v2/operatingsystems/24/architectures_operatingsystems -d {'id': 1}

object created
{
'id': 555
'operatingsystem_id': 24
'architecture_id': 1
}

Delete an association
DELETE api/v2/operatingsystems/24/architectures_operatingsystems/555

This is similar to what Bryan may thought of when he wrote

> What about a
> PUT api/v2/operatingsystems/24/architectures

But the issue here is that PUT requires an ID of a resource to update.

The 'problem' with the atomic restful way is that most 'simple' API's don't expose the database internals such as id #555 on a join table which is meaningless to the user.

Regards,

Joseph

···

----- Original Message ----- > From: "Aaron Stone" > To: foreman-dev@googlegroups.com > Sent: Wednesday, January 29, 2014 6:12:10 PM > Subject: Re: [foreman-dev] Updating many-to-many relationships > > Option #3 is great when you want to rewrite everything, and terrible in all > other cases. Please allow the minimum edit. GET-modify-PUT has two big > problems: race conditions between editors, and large message size. If > you're trying to edit thingy x with parameter y, an URL to x is very > helpful for being specific and atomic. > > > On Wed, Jan 29, 2014 at 7:48 AM, Bryan Kearney > wrote: > > > What about a > > > > PUT api/v2/operatingsystems/24/architectures > > > > ?? > > > > -- bk > > > > > > On 01/29/2014 02:59 AM, Joseph Magen wrote: > > > >> There's a 3rd option and that is to PUT the JSON response from GET > >> > >> GET api/v2/operatingsystems/24 > >> > >> Part of the response includes architectures as a child-node > >> > >> { > >> "id": 24, > >> "name": "CentOs", > >> "architectures": [ > >> { > >> "name": "x86_64", > >> "id": 1 > >> } > >> ] > >> } > >> > >> PUT api/v2/operatingsystems/24 > >> > >> And ad another OS in the JSON data > >> > >> { > >> "id": 24, > >> "name": "CentOs", > >> "architectures": [ > >> { > >> "name": "x86_64", > >> "id": 1 > >> }, > >> { > >> "name": "i386", > >> "id": 2 > >> } > >> ] > >> } > >> > >> Actually, most of the JSON data above is unnecessary. I can just pass in > >> the relationship node with a collection of ids > >> > >> PUT api/v2/operatingsystems/24 > >> > >> { > >> "architectures": [ > >> { > >> "id": 1 > >> }, > >> { > >> "id": 2 > >> } > >> ] > >> } > >> > >> Note that you can NOT add or remove a SINGLE id as in your option #2. I > >> agree with Walden not to implement this. > >> > >> Below, this example CREATES a record in has_and_belongs_to_many > >> relationship table > >> > >> PUT api/v2/operatingsystems/24 > >> > >> { > >> "architectures": [ > >> { > >> "id": 1 > >> }, > >> { > >> "id": 2 > >> } > >> }, > >> { > >> "id": 3 > >> } > >> ] > >> } > >> > >> This DELETES a record in has_and_belongs_to_many relationship table > >> > >> PUT api/v2/operatingsystems/24 > >> > >> { > >> "architectures": [ > >> { > >> "id": 1 > >> } > >> ] > >> } > >> > >> > >> Note that this should work with every has_many or has_and_belongs_to_many > >> relationship even if nested routes or child nodes may not appear for in > >> RABL templates for all objects. > >> > >> > >> In summary, Foreman supports > >> #1) Array on attribute operatingsystem_ids on PUT /architecture/2 > >> > >> { > >> "operatingsystem_ids": [24,25,26] > >> } > >> > >> #3) Array on child not operatingsystems PUT /architecture/2 > >> > >> { > >> "operatingsystems": [{"id": 24},{"id": 25},{"id": 26}] > >> } > >> > >> David, I hope this helps. I agree that the documentation needs to be > >> better. Can you take the initiative on updating the docs once we reach a > >> final decision. > >> > >> Thanks, > >> > >> Joseph > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> ----- Original Message ----- > >> > >>> From: "Walden Raines" > >>> To: foreman-dev@googlegroups.com > >>> Sent: Tuesday, January 28, 2014 10:20:15 PM > >>> Subject: Re: [foreman-dev] Updating many-to-many relationships > >>> > >>> Even though I just followed an existing pattern and implemented a new > >>> occurrence of #2, I prefer #1 as it is more RESTful. > >>> > >>> Cheers, > >>> Walden > >>> > >>> ----- Original Message ----- > >>> From: "David Davis" > >>> To: "foreman-dev" > >>> Sent: Tuesday, January 28, 2014 3:01:29 PM > >>> Subject: [foreman-dev] Updating many-to-many relationships > >>> > >>> So there seems to be a divergence in how Foreman and Katello handle > >>> many-to-many relationships. To give a couple examples of these, one > >>> would be > >>> architectures which have and belong to many OSes in Foreman. In Katello, > >>> content views has and belongs to many repositories There 2-3 options for > >>> updating these relationships: > >>> > >>> 1. Send in operating_system_ids on PUT /architecture/2 > >>> 2. Have add_operating_systems and remove_operating_systems actions that > >>> take > >>> ids > >>> 3. Both 2 and 3 > >>> > >>> Foreman looks like it mostly supports 1 while Katello has a combination > >>> in > >>> its v2 api of 1 and 2 (but not 3). I can see advantages to all: 1 is > >>> simpler > >>> while 2 would maybe be easier to use for the user. 3 seems like a good > >>> option but would be the most work. > >>> > >>> Thoughts? > >>> > >>> David > >>> > >>> -- > >>> You received this message because you are subscribed to the Google Groups > >>> "foreman-dev" group. > >>> To unsubscribe from this group and stop receiving emails from it, send an > >>> email to foreman-dev+unsubscribe@googlegroups.com. > >>> For more options, visit https://groups.google.com/groups/opt_out. > >>> > >>> -- > >>> You received this message because you are subscribed to the Google Groups > >>> "foreman-dev" group. > >>> To unsubscribe from this group and stop receiving emails from it, send an > >>> email to foreman-dev+unsubscribe@googlegroups.com. > >>> For more options, visit https://groups.google.com/groups/opt_out. > >>> > >>> > >> > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-dev+unsubscribe@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. >

Walden_Raines · January 29, 2014, 2:32pm

I like option #3 even better, thanks Joseph.

We may have reached a decision unless there are any dissenting opinions that remain unvoiced.

Cheers,
Walden

···

----- Original Message ----- From: "Joseph Magen" To: foreman-dev@googlegroups.com Sent: Wednesday, January 29, 2014 8:22:11 AM Subject: Re: [foreman-dev] Updating many-to-many relationships

Hi David,

Rails comes out-of-the-box with support for column_names_ids = [1,2,3,4]

Option #3 I created a before_filter in api/v2/base_controller.rb

github.com

isratrade/foreman/blob/inherit_loc/app/controllers/api/v2/base_controller.rb#L11


module Api
module V2
  class BaseController < Api::BaseController
    include Api::Version2


    resource_description do
      api_version "v2"
      app_info "Foreman v2 is currently in development and is not the default version. You may use v2 by either passing 'version=2' in the Accept Header or entering api/v2/ in the URL."
    end


    before_filter :setup_has_many_params, :only => [:create, :update]
    layout 'api/v2/layouts/index_layout', :only => :index


    helper_method :root_node_name, :metadata_total, :metadata_subtotal, :metadata_search,
                  :metadata_order, :metadata_by, :metadata_page, :metadata_per_page


    def root_node_name
      @root_node_name ||= if Rabl.configuration.use_controller_name_as_json_root
                            controller_name.split('/').last
                          elsif params['root_name'].present?
                            params['root_name']

Basically, I manipulated the input to convert from an array of JSON objects to get attribute :column_names_ids = [1,2,3,4] which is what Rails likes in the standard update_attributes method
Note, column_names_names = [“name1”, “name2”] also works.

Joseph

----- Original Message -----

From: “David Davis” daviddavis@redhat.com
To: foreman-dev@googlegroups.com
Sent: Wednesday, January 29, 2014 3:13:57 PM
Subject: Re: [foreman-dev] Updating many-to-many relationships

Joseph,

I’ll update the docs when we reach a decision. Question though: how did you
all add support for the third option you outlined? Does it comes with Rails?

David

----- Original Message -----

From: “Joseph Magen” jmagen@redhat.com
To: foreman-dev@googlegroups.com
Sent: Wednesday, January 29, 2014 2:59:08 AM
Subject: Re: [foreman-dev] Updating many-to-many relationships

There’s a 3rd option and that is to PUT the JSON response from GET

GET api/v2/operatingsystems/24

Part of the response includes architectures as a child-node

{
“id”: 24,
“name”: “CentOs”,
“architectures”: [
{
“name”: “x86_64”,
“id”: 1
}
]
}

PUT api/v2/operatingsystems/24

And ad another OS in the JSON data

{
“id”: 24,
“name”: “CentOs”,
“architectures”: [
{
“name”: “x86_64”,
“id”: 1
},
{
“name”: “i386”,
“id”: 2
}
]
}

Actually, most of the JSON data above is unnecessary. I can just pass in
the
relationship node with a collection of ids

PUT api/v2/operatingsystems/24

{
“architectures”: [
{
“id”: 1
},
{
“id”: 2
}
]
}

Note that you can NOT add or remove a SINGLE id as in your option #2. I
agree with Walden not to implement this.

Below, this example CREATES a record in has_and_belongs_to_many
relationship
table

PUT api/v2/operatingsystems/24

{
“architectures”: [
{
“id”: 1
},
{
“id”: 2
}
},
{
“id”: 3
}
]
}

This DELETES a record in has_and_belongs_to_many relationship table

PUT api/v2/operatingsystems/24

{
“architectures”: [
{
“id”: 1
}
]
}

Note that this should work with every has_many or has_and_belongs_to_many
relationship even if nested routes or child nodes may not appear for in
RABL
templates for all objects.

In summary, Foreman supports
#1) Array on attribute operatingsystem_ids on PUT /architecture/2

{
“operatingsystem_ids”: [24,25,26]
}

#3) Array on child not operatingsystems PUT /architecture/2

{
“operatingsystems”: [{“id”: 24},{“id”: 25},{“id”: 26}]
}

David, I hope this helps. I agree that the documentation needs to be
better.
Can you take the initiative on updating the docs once we reach a final
decision.

Thanks,

Joseph

----- Original Message -----

From: “Walden Raines” walden@redhat.com
To: foreman-dev@googlegroups.com
Sent: Tuesday, January 28, 2014 10:20:15 PM
Subject: Re: [foreman-dev] Updating many-to-many relationships

Even though I just followed an existing pattern and implemented a new
occurrence of #2, I prefer #1 as it is more RESTful.

Cheers,
Walden

----- Original Message -----
From: “David Davis” daviddavis@redhat.com
To: “foreman-dev” foreman-dev@googlegroups.com
Sent: Tuesday, January 28, 2014 3:01:29 PM
Subject: [foreman-dev] Updating many-to-many relationships

So there seems to be a divergence in how Foreman and Katello handle
many-to-many relationships. To give a couple examples of these, one would
be
architectures which have and belong to many OSes in Foreman. In Katello,
content views has and belongs to many repositories There 2-3 options for
updating these relationships:

Send in operating_system_ids on PUT /architecture/2

Have add_operating_systems and remove_operating_systems actions that
take
ids

Both 2 and 3

Foreman looks like it mostly supports 1 while Katello has a combination
in
its v2 api of 1 and 2 (but not 3). I can see advantages to all: 1 is
simpler
while 2 would maybe be easier to use for the user. 3 seems like a good
option but would be the most work.

Thoughts?

David

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

–
You received this message because you are subscribed to the Google Groups “foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

daviddavis · January 30, 2014, 12:21pm

What about something like this?

PUT api/v2/operatingsystems/24 -d {'add_architecture_ids': 1}

Seems like it would be easy to implement, atomic, and RESTful?

David

···

----- Original Message ----- > From: "Joseph Magen" > To: foreman-dev@googlegroups.com > Sent: Thursday, January 30, 2014 2:42:10 AM > Subject: Re: [foreman-dev] Updating many-to-many relationships > > To be specific and atomic, then you need to treat the many-to-many relation > as its own resource. This is not the case with our example > > PUT api/v2/operatingsystems/24 > > which update all the attributes AND associations for resource operating > system #24 > > The RESTful way to only add or delete an association (similar to what we did > for host_classes and hostgroup_classes) is this below: (Note that BOTH the > architecture id and operating system id's already exist) > > Create a new association > POST api/v2/operatingsystems/24/architectures_operatingsystems -d {'id': 1} > > object created > { > 'id': 555 > 'operatingsystem_id': 24 > 'architecture_id': 1 > } > > Delete an association > DELETE api/v2/operatingsystems/24/architectures_operatingsystems/555 > > This is similar to what Bryan may thought of when he wrote > > > What about a > > PUT api/v2/operatingsystems/24/architectures > > But the issue here is that PUT requires an ID of a resource to update. > > The 'problem' with the atomic restful way is that most 'simple' API's don't > expose the database internals such as id #555 on a join table which is > meaningless to the user. > > Regards, > > Joseph > > > > > ----- Original Message ----- > > From: "Aaron Stone" > > To: foreman-dev@googlegroups.com > > Sent: Wednesday, January 29, 2014 6:12:10 PM > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > Option #3 is great when you want to rewrite everything, and terrible in all > > other cases. Please allow the minimum edit. GET-modify-PUT has two big > > problems: race conditions between editors, and large message size. If > > you're trying to edit thingy x with parameter y, an URL to x is very > > helpful for being specific and atomic. > > > > > > On Wed, Jan 29, 2014 at 7:48 AM, Bryan Kearney > > wrote: > > > > > What about a > > > > > > PUT api/v2/operatingsystems/24/architectures > > > > > > ?? > > > > > > -- bk > > > > > > > > > On 01/29/2014 02:59 AM, Joseph Magen wrote: > > > > > >> There's a 3rd option and that is to PUT the JSON response from GET > > >> > > >> GET api/v2/operatingsystems/24 > > >> > > >> Part of the response includes architectures as a child-node > > >> > > >> { > > >> "id": 24, > > >> "name": "CentOs", > > >> "architectures": [ > > >> { > > >> "name": "x86_64", > > >> "id": 1 > > >> } > > >> ] > > >> } > > >> > > >> PUT api/v2/operatingsystems/24 > > >> > > >> And ad another OS in the JSON data > > >> > > >> { > > >> "id": 24, > > >> "name": "CentOs", > > >> "architectures": [ > > >> { > > >> "name": "x86_64", > > >> "id": 1 > > >> }, > > >> { > > >> "name": "i386", > > >> "id": 2 > > >> } > > >> ] > > >> } > > >> > > >> Actually, most of the JSON data above is unnecessary. I can just pass > > >> in > > >> the relationship node with a collection of ids > > >> > > >> PUT api/v2/operatingsystems/24 > > >> > > >> { > > >> "architectures": [ > > >> { > > >> "id": 1 > > >> }, > > >> { > > >> "id": 2 > > >> } > > >> ] > > >> } > > >> > > >> Note that you can NOT add or remove a SINGLE id as in your option #2. I > > >> agree with Walden not to implement this. > > >> > > >> Below, this example CREATES a record in has_and_belongs_to_many > > >> relationship table > > >> > > >> PUT api/v2/operatingsystems/24 > > >> > > >> { > > >> "architectures": [ > > >> { > > >> "id": 1 > > >> }, > > >> { > > >> "id": 2 > > >> } > > >> }, > > >> { > > >> "id": 3 > > >> } > > >> ] > > >> } > > >> > > >> This DELETES a record in has_and_belongs_to_many relationship table > > >> > > >> PUT api/v2/operatingsystems/24 > > >> > > >> { > > >> "architectures": [ > > >> { > > >> "id": 1 > > >> } > > >> ] > > >> } > > >> > > >> > > >> Note that this should work with every has_many or > > >> has_and_belongs_to_many > > >> relationship even if nested routes or child nodes may not appear for in > > >> RABL templates for all objects. > > >> > > >> > > >> In summary, Foreman supports > > >> #1) Array on attribute operatingsystem_ids on PUT /architecture/2 > > >> > > >> { > > >> "operatingsystem_ids": [24,25,26] > > >> } > > >> > > >> #3) Array on child not operatingsystems PUT /architecture/2 > > >> > > >> { > > >> "operatingsystems": [{"id": 24},{"id": 25},{"id": 26}] > > >> } > > >> > > >> David, I hope this helps. I agree that the documentation needs to be > > >> better. Can you take the initiative on updating the docs once we reach a > > >> final decision. > > >> > > >> Thanks, > > >> > > >> Joseph > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> ----- Original Message ----- > > >> > > >>> From: "Walden Raines" > > >>> To: foreman-dev@googlegroups.com > > >>> Sent: Tuesday, January 28, 2014 10:20:15 PM > > >>> Subject: Re: [foreman-dev] Updating many-to-many relationships > > >>> > > >>> Even though I just followed an existing pattern and implemented a new > > >>> occurrence of #2, I prefer #1 as it is more RESTful. > > >>> > > >>> Cheers, > > >>> Walden > > >>> > > >>> ----- Original Message ----- > > >>> From: "David Davis" > > >>> To: "foreman-dev" > > >>> Sent: Tuesday, January 28, 2014 3:01:29 PM > > >>> Subject: [foreman-dev] Updating many-to-many relationships > > >>> > > >>> So there seems to be a divergence in how Foreman and Katello handle > > >>> many-to-many relationships. To give a couple examples of these, one > > >>> would be > > >>> architectures which have and belong to many OSes in Foreman. In > > >>> Katello, > > >>> content views has and belongs to many repositories There 2-3 options > > >>> for > > >>> updating these relationships: > > >>> > > >>> 1. Send in operating_system_ids on PUT /architecture/2 > > >>> 2. Have add_operating_systems and remove_operating_systems actions that > > >>> take > > >>> ids > > >>> 3. Both 2 and 3 > > >>> > > >>> Foreman looks like it mostly supports 1 while Katello has a combination > > >>> in > > >>> its v2 api of 1 and 2 (but not 3). I can see advantages to all: 1 is > > >>> simpler > > >>> while 2 would maybe be easier to use for the user. 3 seems like a good > > >>> option but would be the most work. > > >>> > > >>> Thoughts? > > >>> > > >>> David > > >>> > > >>> -- > > >>> You received this message because you are subscribed to the Google > > >>> Groups > > >>> "foreman-dev" group. > > >>> To unsubscribe from this group and stop receiving emails from it, send > > >>> an > > >>> email to foreman-dev+unsubscribe@googlegroups.com. > > >>> For more options, visit https://groups.google.com/groups/opt_out. > > >>> > > >>> -- > > >>> You received this message because you are subscribed to the Google > > >>> Groups > > >>> "foreman-dev" group. > > >>> To unsubscribe from this group and stop receiving emails from it, send > > >>> an > > >>> email to foreman-dev+unsubscribe@googlegroups.com. > > >>> For more options, visit https://groups.google.com/groups/opt_out. > > >>> > > >>> > > >> > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "foreman-dev" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-dev+unsubscribe@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. >

Bryan_Kearney · January 30, 2014, 1:13pm

> To be specific and atomic, then you need to treat the many-to-many relation as its own resource. This is not the case with our example
>
> PUT api/v2/operatingsystems/24
>
> which update all the attributes AND associations for resource operating system #24
>
> The RESTful way to only add or delete an association (similar to what we did for host_classes and hostgroup_classes) is this below: (Note that BOTH the architecture id and operating system id's already exist)
>
> Create a new association
> POST api/v2/operatingsystems/24/architectures_operatingsystems -d {'id': 1}
>
> object created
> {
> 'id': 555
> 'operatingsystem_id': 24
> 'architecture_id': 1
> }
>
> Delete an association
> DELETE api/v2/operatingsystems/24/architectures_operatingsystems/555
>
> This is similar to what Bryan may thought of when he wrote
>
>> What about a
>> PUT api/v2/operatingsystems/24/architectures
>
> But the issue here is that PUT requires an ID of a resource to update.

yeah… I should have put POST.

>
> The 'problem' with the atomic restful way is that most 'simple' API's don't expose the database internals such as id #555 on a join table which is meaningless to the user.

I would make it architectures. That way the join parrt is hidden a bit.

– bk

···

On 01/30/2014 02:42 AM, Joseph Magen wrote:

Joseph_Magen · January 29, 2014, 3:14pm

One point of clarification referring to the thread that I started on Dec 24 with subject: Subject: API v2 adding/removing associations: to wrap parameters or not?

PUT /architecture/2

This works - _ids AND WRAPPED
{
"architecture": {
"operatingsystem_ids": [24,25,26]
}
}
This works - child node and NOT WRAPPED (like GET)
{
"operatingsystems": [{"id": 24},{"id": 25},{"id": 26}]
}
This does NOT work - child node and WRAPPED
{
"architecture": {
"operatingsystems": [{"id": 24},{"id": 25},{"id": 26}]
}
}
This does NOT work - _ids and NOT WRAPPED
{
"operatingsystem_ids": [24,25,26]
}

4 is the example that I previously gave, but it current doesn't work. If we want #3 and #4 to work, then I need to modify

github.com

theforeman/foreman/blob/develop/app/controllers/api/v2/base_controller.rb#L59-71


                      end
end


def metadata_total
  @total ||= resource_scope.try(:count).to_i
end


def metadata_subtotal
  if params[:search].present?
    @subtotal ||= instance_variable_get("@#{controller_name}").try(:count).to_i
  else
    @subtotal ||= metadata_total
  end
end


def metadata_search
  @search ||= params[:search]
end


def metadata_order
  @order ||=  params[:order].present? && (order_array = params[:order].split(' ')).any? ? (order_array[1] || 'ASC') : nil

···

----- Original Message ----- > From: "Walden Raines" > To: foreman-dev@googlegroups.com > Sent: Wednesday, January 29, 2014 4:32:23 PM > Subject: Re: [foreman-dev] Updating many-to-many relationships > > I like option #3 even better, thanks Joseph. > > We may have reached a decision unless there are any dissenting opinions that > remain unvoiced. > > Cheers, > Walden > > > ----- Original Message ----- > From: "Joseph Magen" > To: foreman-dev@googlegroups.com > Sent: Wednesday, January 29, 2014 8:22:11 AM > Subject: Re: [foreman-dev] Updating many-to-many relationships > > Hi David, > > Rails comes out-of-the-box with support for column_names_ids = [1,2,3,4] > > Option #3 I created a before_filter in api/v2/base_controller.rb > > https://github.com/isratrade/foreman/blob/inherit_loc/app/controllers/api/v2/base_controller.rb#L11 > > Basically, I manipulated the input to convert from an array of JSON objects > to get attribute :column_names_ids = [1,2,3,4] which is what Rails likes in > the standard `update_attributes` method > Note, column_names_names = ["name1", "name2"] also works. > > Joseph > > > > ----- Original Message ----- > > From: "David Davis" > > To: foreman-dev@googlegroups.com > > Sent: Wednesday, January 29, 2014 3:13:57 PM > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > Joseph, > > > > I'll update the docs when we reach a decision. Question though: how did you > > all add support for the third option you outlined? Does it comes with > > Rails? > > > > David > > > > ----- Original Message ----- > > > From: "Joseph Magen" > > > To: foreman-dev@googlegroups.com > > > Sent: Wednesday, January 29, 2014 2:59:08 AM > > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > > > There's a 3rd option and that is to PUT the JSON response from GET > > > > > > GET api/v2/operatingsystems/24 > > > > > > Part of the response includes architectures as a child-node > > > > > > { > > > "id": 24, > > > "name": "CentOs", > > > "architectures": [ > > > { > > > "name": "x86_64", > > > "id": 1 > > > } > > > ] > > > } > > > > > > PUT api/v2/operatingsystems/24 > > > > > > And ad another OS in the JSON data > > > > > > { > > > "id": 24, > > > "name": "CentOs", > > > "architectures": [ > > > { > > > "name": "x86_64", > > > "id": 1 > > > }, > > > { > > > "name": "i386", > > > "id": 2 > > > } > > > ] > > > } > > > > > > Actually, most of the JSON data above is unnecessary. I can just pass in > > > the > > > relationship node with a collection of ids > > > > > > PUT api/v2/operatingsystems/24 > > > > > > { > > > "architectures": [ > > > { > > > "id": 1 > > > }, > > > { > > > "id": 2 > > > } > > > ] > > > } > > > > > > Note that you can NOT add or remove a SINGLE id as in your option #2. I > > > agree with Walden not to implement this. > > > > > > Below, this example CREATES a record in has_and_belongs_to_many > > > relationship > > > table > > > > > > PUT api/v2/operatingsystems/24 > > > > > > { > > > "architectures": [ > > > { > > > "id": 1 > > > }, > > > { > > > "id": 2 > > > } > > > }, > > > { > > > "id": 3 > > > } > > > ] > > > } > > > > > > This DELETES a record in has_and_belongs_to_many relationship table > > > > > > PUT api/v2/operatingsystems/24 > > > > > > { > > > "architectures": [ > > > { > > > "id": 1 > > > } > > > ] > > > } > > > > > > > > > Note that this should work with every has_many or has_and_belongs_to_many > > > relationship even if nested routes or child nodes may not appear for in > > > RABL > > > templates for all objects. > > > > > > > > > In summary, Foreman supports > > > #1) Array on attribute operatingsystem_ids on PUT /architecture/2 > > > > > > { > > > "operatingsystem_ids": [24,25,26] > > > } > > > > > > #3) Array on child not operatingsystems PUT /architecture/2 > > > > > > { > > > "operatingsystems": [{"id": 24},{"id": 25},{"id": 26}] > > > } > > > > > > David, I hope this helps. I agree that the documentation needs to be > > > better. > > > Can you take the initiative on updating the docs once we reach a final > > > decision. > > > > > > Thanks, > > > > > > Joseph > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Walden Raines" > > > > To: foreman-dev@googlegroups.com > > > > Sent: Tuesday, January 28, 2014 10:20:15 PM > > > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > > > > > Even though I just followed an existing pattern and implemented a new > > > > occurrence of #2, I prefer #1 as it is more RESTful. > > > > > > > > Cheers, > > > > Walden > > > > > > > > ----- Original Message ----- > > > > From: "David Davis" > > > > To: "foreman-dev" > > > > Sent: Tuesday, January 28, 2014 3:01:29 PM > > > > Subject: [foreman-dev] Updating many-to-many relationships > > > > > > > > So there seems to be a divergence in how Foreman and Katello handle > > > > many-to-many relationships. To give a couple examples of these, one > > > > would > > > > be > > > > architectures which have and belong to many OSes in Foreman. In > > > > Katello, > > > > content views has and belongs to many repositories There 2-3 options > > > > for > > > > updating these relationships: > > > > > > > > 1. Send in operating_system_ids on PUT /architecture/2 > > > > 2. Have add_operating_systems and remove_operating_systems actions that > > > > take > > > > ids > > > > 3. Both 2 and 3 > > > > > > > > Foreman looks like it mostly supports 1 while Katello has a combination > > > > in > > > > its v2 api of 1 and 2 (but not 3). I can see advantages to all: 1 is > > > > simpler > > > > while 2 would maybe be easier to use for the user. 3 seems like a good > > > > option but would be the most work. > > > > > > > > Thoughts? > > > > > > > > David > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups > > > > "foreman-dev" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an > > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups > > > > "foreman-dev" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an > > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "foreman-dev" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-dev+unsubscribe@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. >

thomasmckay · January 29, 2014, 3:18pm

I like option #3 but I have concerns about race conditions between calls since the GET then PUT is not atomic.

user A GET organization
user B GET organization
user A PUT organization, removing an architecture
user B PUT organization, adding an architecture

In the above, step 3 is effectively lost since step 4 included the architecture that step 3 meant to delete.

To prevent this, some sort of versioning field should be required in the PUTs (@daviddavis suggested that the updated-at could be used). This would result in step 4 failing with an error since step 3 would have changed the version of the object.

Without this, I believe that we will need to have methods to add and remove individual relations.

···

----- Original Message ----- > From: "Walden Raines" > To: foreman-dev@googlegroups.com > Sent: Wednesday, January 29, 2014 9:32:23 AM > Subject: Re: [foreman-dev] Updating many-to-many relationships > > I like option #3 even better, thanks Joseph. > > We may have reached a decision unless there are any dissenting opinions that > remain unvoiced. > > Cheers, > Walden > > > ----- Original Message ----- > From: "Joseph Magen" > To: foreman-dev@googlegroups.com > Sent: Wednesday, January 29, 2014 8:22:11 AM > Subject: Re: [foreman-dev] Updating many-to-many relationships > > Hi David, > > Rails comes out-of-the-box with support for column_names_ids = [1,2,3,4] > > Option #3 I created a before_filter in api/v2/base_controller.rb > > https://github.com/isratrade/foreman/blob/inherit_loc/app/controllers/api/v2/base_controller.rb#L11 > > Basically, I manipulated the input to convert from an array of JSON objects > to get attribute :column_names_ids = [1,2,3,4] which is what Rails likes in > the standard `update_attributes` method > Note, column_names_names = ["name1", "name2"] also works. > > Joseph > > > > ----- Original Message ----- > > From: "David Davis" > > To: foreman-dev@googlegroups.com > > Sent: Wednesday, January 29, 2014 3:13:57 PM > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > Joseph, > > > > I'll update the docs when we reach a decision. Question though: how did you > > all add support for the third option you outlined? Does it comes with > > Rails? > > > > David > > > > ----- Original Message ----- > > > From: "Joseph Magen" > > > To: foreman-dev@googlegroups.com > > > Sent: Wednesday, January 29, 2014 2:59:08 AM > > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > > > There's a 3rd option and that is to PUT the JSON response from GET > > > > > > GET api/v2/operatingsystems/24 > > > > > > Part of the response includes architectures as a child-node > > > > > > { > > > "id": 24, > > > "name": "CentOs", > > > "architectures": [ > > > { > > > "name": "x86_64", > > > "id": 1 > > > } > > > ] > > > } > > > > > > PUT api/v2/operatingsystems/24 > > > > > > And ad another OS in the JSON data > > > > > > { > > > "id": 24, > > > "name": "CentOs", > > > "architectures": [ > > > { > > > "name": "x86_64", > > > "id": 1 > > > }, > > > { > > > "name": "i386", > > > "id": 2 > > > } > > > ] > > > } > > > > > > Actually, most of the JSON data above is unnecessary. I can just pass in > > > the > > > relationship node with a collection of ids > > > > > > PUT api/v2/operatingsystems/24 > > > > > > { > > > "architectures": [ > > > { > > > "id": 1 > > > }, > > > { > > > "id": 2 > > > } > > > ] > > > } > > > > > > Note that you can NOT add or remove a SINGLE id as in your option #2. I > > > agree with Walden not to implement this. > > > > > > Below, this example CREATES a record in has_and_belongs_to_many > > > relationship > > > table > > > > > > PUT api/v2/operatingsystems/24 > > > > > > { > > > "architectures": [ > > > { > > > "id": 1 > > > }, > > > { > > > "id": 2 > > > } > > > }, > > > { > > > "id": 3 > > > } > > > ] > > > } > > > > > > This DELETES a record in has_and_belongs_to_many relationship table > > > > > > PUT api/v2/operatingsystems/24 > > > > > > { > > > "architectures": [ > > > { > > > "id": 1 > > > } > > > ] > > > } > > > > > > > > > Note that this should work with every has_many or has_and_belongs_to_many > > > relationship even if nested routes or child nodes may not appear for in > > > RABL > > > templates for all objects. > > > > > > > > > In summary, Foreman supports > > > #1) Array on attribute operatingsystem_ids on PUT /architecture/2 > > > > > > { > > > "operatingsystem_ids": [24,25,26] > > > } > > > > > > #3) Array on child not operatingsystems PUT /architecture/2 > > > > > > { > > > "operatingsystems": [{"id": 24},{"id": 25},{"id": 26}] > > > } > > > > > > David, I hope this helps. I agree that the documentation needs to be > > > better. > > > Can you take the initiative on updating the docs once we reach a final > > > decision. > > > > > > Thanks, > > > > > > Joseph > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Walden Raines" > > > > To: foreman-dev@googlegroups.com > > > > Sent: Tuesday, January 28, 2014 10:20:15 PM > > > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > > > > > Even though I just followed an existing pattern and implemented a new > > > > occurrence of #2, I prefer #1 as it is more RESTful. > > > > > > > > Cheers, > > > > Walden > > > > > > > > ----- Original Message ----- > > > > From: "David Davis" > > > > To: "foreman-dev" > > > > Sent: Tuesday, January 28, 2014 3:01:29 PM > > > > Subject: [foreman-dev] Updating many-to-many relationships > > > > > > > > So there seems to be a divergence in how Foreman and Katello handle > > > > many-to-many relationships. To give a couple examples of these, one > > > > would > > > > be > > > > architectures which have and belong to many OSes in Foreman. In > > > > Katello, > > > > content views has and belongs to many repositories There 2-3 options > > > > for > > > > updating these relationships: > > > > > > > > 1. Send in operating_system_ids on PUT /architecture/2 > > > > 2. Have add_operating_systems and remove_operating_systems actions that > > > > take > > > > ids > > > > 3. Both 2 and 3 > > > > > > > > Foreman looks like it mostly supports 1 while Katello has a combination > > > > in > > > > its v2 api of 1 and 2 (but not 3). I can see advantages to all: 1 is > > > > simpler > > > > while 2 would maybe be easier to use for the user. 3 seems like a good > > > > option but would be the most work. > > > > > > > > Thoughts? > > > > > > > > David > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups > > > > "foreman-dev" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an > > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups > > > > "foreman-dev" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an > > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "foreman-dev" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-dev+unsubscribe@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. >

Joseph_Magen · January 30, 2014, 12:48pm

David,

You usually don't have a function as a data attribute, even though Rails generate the *_ids magic methods. It's possible what you suggest although not RESTful. In fact, to be RESTful, we should not create any NEW objects with PUT.

Joseph

···

----- Original Message ----- > From: "David Davis" > To: foreman-dev@googlegroups.com > Sent: Thursday, January 30, 2014 2:21:43 PM > Subject: Re: [foreman-dev] Updating many-to-many relationships > > What about something like this? > > PUT api/v2/operatingsystems/24 -d {'add_architecture_ids': 1} > > Seems like it would be easy to implement, atomic, and RESTful? > > David > > ----- Original Message ----- > > From: "Joseph Magen" > > To: foreman-dev@googlegroups.com > > Sent: Thursday, January 30, 2014 2:42:10 AM > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > To be specific and atomic, then you need to treat the many-to-many relation > > as its own resource. This is not the case with our example > > > > PUT api/v2/operatingsystems/24 > > > > which update all the attributes AND associations for resource operating > > system #24 > > > > The RESTful way to only add or delete an association (similar to what we > > did > > for host_classes and hostgroup_classes) is this below: (Note that BOTH the > > architecture id and operating system id's already exist) > > > > Create a new association > > POST api/v2/operatingsystems/24/architectures_operatingsystems -d {'id': 1} > > > > object created > > { > > 'id': 555 > > 'operatingsystem_id': 24 > > 'architecture_id': 1 > > } > > > > Delete an association > > DELETE api/v2/operatingsystems/24/architectures_operatingsystems/555 > > > > This is similar to what Bryan may thought of when he wrote > > > > > What about a > > > PUT api/v2/operatingsystems/24/architectures > > > > But the issue here is that PUT requires an ID of a resource to update. > > > > The 'problem' with the atomic restful way is that most 'simple' API's don't > > expose the database internals such as id #555 on a join table which is > > meaningless to the user. > > > > Regards, > > > > Joseph > > > > > > > > > > ----- Original Message ----- > > > From: "Aaron Stone" > > > To: foreman-dev@googlegroups.com > > > Sent: Wednesday, January 29, 2014 6:12:10 PM > > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > > > Option #3 is great when you want to rewrite everything, and terrible in > > > all > > > other cases. Please allow the minimum edit. GET-modify-PUT has two big > > > problems: race conditions between editors, and large message size. If > > > you're trying to edit thingy x with parameter y, an URL to x is very > > > helpful for being specific and atomic. > > > > > > > > > On Wed, Jan 29, 2014 at 7:48 AM, Bryan Kearney > > > wrote: > > > > > > > What about a > > > > > > > > PUT api/v2/operatingsystems/24/architectures > > > > > > > > ?? > > > > > > > > -- bk > > > > > > > > > > > > On 01/29/2014 02:59 AM, Joseph Magen wrote: > > > > > > > >> There's a 3rd option and that is to PUT the JSON response from GET > > > >> > > > >> GET api/v2/operatingsystems/24 > > > >> > > > >> Part of the response includes architectures as a child-node > > > >> > > > >> { > > > >> "id": 24, > > > >> "name": "CentOs", > > > >> "architectures": [ > > > >> { > > > >> "name": "x86_64", > > > >> "id": 1 > > > >> } > > > >> ] > > > >> } > > > >> > > > >> PUT api/v2/operatingsystems/24 > > > >> > > > >> And ad another OS in the JSON data > > > >> > > > >> { > > > >> "id": 24, > > > >> "name": "CentOs", > > > >> "architectures": [ > > > >> { > > > >> "name": "x86_64", > > > >> "id": 1 > > > >> }, > > > >> { > > > >> "name": "i386", > > > >> "id": 2 > > > >> } > > > >> ] > > > >> } > > > >> > > > >> Actually, most of the JSON data above is unnecessary. I can just pass > > > >> in > > > >> the relationship node with a collection of ids > > > >> > > > >> PUT api/v2/operatingsystems/24 > > > >> > > > >> { > > > >> "architectures": [ > > > >> { > > > >> "id": 1 > > > >> }, > > > >> { > > > >> "id": 2 > > > >> } > > > >> ] > > > >> } > > > >> > > > >> Note that you can NOT add or remove a SINGLE id as in your option #2. > > > >> I > > > >> agree with Walden not to implement this. > > > >> > > > >> Below, this example CREATES a record in has_and_belongs_to_many > > > >> relationship table > > > >> > > > >> PUT api/v2/operatingsystems/24 > > > >> > > > >> { > > > >> "architectures": [ > > > >> { > > > >> "id": 1 > > > >> }, > > > >> { > > > >> "id": 2 > > > >> } > > > >> }, > > > >> { > > > >> "id": 3 > > > >> } > > > >> ] > > > >> } > > > >> > > > >> This DELETES a record in has_and_belongs_to_many relationship table > > > >> > > > >> PUT api/v2/operatingsystems/24 > > > >> > > > >> { > > > >> "architectures": [ > > > >> { > > > >> "id": 1 > > > >> } > > > >> ] > > > >> } > > > >> > > > >> > > > >> Note that this should work with every has_many or > > > >> has_and_belongs_to_many > > > >> relationship even if nested routes or child nodes may not appear for > > > >> in > > > >> RABL templates for all objects. > > > >> > > > >> > > > >> In summary, Foreman supports > > > >> #1) Array on attribute operatingsystem_ids on PUT /architecture/2 > > > >> > > > >> { > > > >> "operatingsystem_ids": [24,25,26] > > > >> } > > > >> > > > >> #3) Array on child not operatingsystems PUT /architecture/2 > > > >> > > > >> { > > > >> "operatingsystems": [{"id": 24},{"id": 25},{"id": 26}] > > > >> } > > > >> > > > >> David, I hope this helps. I agree that the documentation needs to be > > > >> better. Can you take the initiative on updating the docs once we reach > > > >> a > > > >> final decision. > > > >> > > > >> Thanks, > > > >> > > > >> Joseph > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> ----- Original Message ----- > > > >> > > > >>> From: "Walden Raines" > > > >>> To: foreman-dev@googlegroups.com > > > >>> Sent: Tuesday, January 28, 2014 10:20:15 PM > > > >>> Subject: Re: [foreman-dev] Updating many-to-many relationships > > > >>> > > > >>> Even though I just followed an existing pattern and implemented a new > > > >>> occurrence of #2, I prefer #1 as it is more RESTful. > > > >>> > > > >>> Cheers, > > > >>> Walden > > > >>> > > > >>> ----- Original Message ----- > > > >>> From: "David Davis" > > > >>> To: "foreman-dev" > > > >>> Sent: Tuesday, January 28, 2014 3:01:29 PM > > > >>> Subject: [foreman-dev] Updating many-to-many relationships > > > >>> > > > >>> So there seems to be a divergence in how Foreman and Katello handle > > > >>> many-to-many relationships. To give a couple examples of these, one > > > >>> would be > > > >>> architectures which have and belong to many OSes in Foreman. In > > > >>> Katello, > > > >>> content views has and belongs to many repositories There 2-3 options > > > >>> for > > > >>> updating these relationships: > > > >>> > > > >>> 1. Send in operating_system_ids on PUT /architecture/2 > > > >>> 2. Have add_operating_systems and remove_operating_systems actions > > > >>> that > > > >>> take > > > >>> ids > > > >>> 3. Both 2 and 3 > > > >>> > > > >>> Foreman looks like it mostly supports 1 while Katello has a > > > >>> combination > > > >>> in > > > >>> its v2 api of 1 and 2 (but not 3). I can see advantages to all: 1 is > > > >>> simpler > > > >>> while 2 would maybe be easier to use for the user. 3 seems like a > > > >>> good > > > >>> option but would be the most work. > > > >>> > > > >>> Thoughts? > > > >>> > > > >>> David > > > >>> > > > >>> -- > > > >>> You received this message because you are subscribed to the Google > > > >>> Groups > > > >>> "foreman-dev" group. > > > >>> To unsubscribe from this group and stop receiving emails from it, > > > >>> send > > > >>> an > > > >>> email to foreman-dev+unsubscribe@googlegroups.com. > > > >>> For more options, visit https://groups.google.com/groups/opt_out. > > > >>> > > > >>> -- > > > >>> You received this message because you are subscribed to the Google > > > >>> Groups > > > >>> "foreman-dev" group. > > > >>> To unsubscribe from this group and stop receiving emails from it, > > > >>> send > > > >>> an > > > >>> email to foreman-dev+unsubscribe@googlegroups.com. > > > >>> For more options, visit https://groups.google.com/groups/opt_out. > > > >>> > > > >>> > > > >> > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups > > > > "foreman-dev" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an > > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "foreman-dev" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-dev+unsubscribe@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. >

Joseph_Magen · January 30, 2014, 1:19pm

> From: "Bryan Kearney" <bryan.kearney@gmail.com>
> To: foreman-dev@googlegroups.com
> Sent: Thursday, January 30, 2014 3:13:37 PM
> Subject: Re: [foreman-dev] Updating many-to-many relationships
>
> > To be specific and atomic, then you need to treat the many-to-many relation
> > as its own resource. This is not the case with our example
> >
> > PUT api/v2/operatingsystems/24
> >
> > which update all the attributes AND associations for resource operating
> > system #24
> >
> > The RESTful way to only add or delete an association (similar to what we
> > did for host_classes and hostgroup_classes) is this below: (Note that BOTH
> > the architecture id and operating system id's already exist)
> >
> > Create a new association
> > POST api/v2/operatingsystems/24/architectures_operatingsystems -d {'id': 1}
> >
> > object created
> > {
> > 'id': 555
> > 'operatingsystem_id': 24
> > 'architecture_id': 1
> > }
> >
> > Delete an association
> > DELETE api/v2/operatingsystems/24/architectures_operatingsystems/555
> >
> > This is similar to what Bryan may thought of when he wrote
> >
> >> What about a
> >> PUT api/v2/operatingsystems/24/architectures
> >
> > But the issue here is that PUT requires an ID of a resource to update.
>
>
> yeah… I should have put POST.
>
> >
> > The 'problem' with the atomic restful way is that most 'simple' API's don't
> > expose the database internals such as id #555 on a join table which is
> > meaningless to the user.
>
> I would make it architectures. That way the join parrt is hidden a bit.

POST api/v2/operatingsystems/24/architectures -d {'id': 1}

This would be confusing, since in RESTful style, a POST on a collection (architectures) creates a new architecture.

···

----- Original Message ----- > On 01/30/2014 02:42 AM, Joseph Magen wrote:

– bk

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

daviddavis · January 29, 2014, 3:21pm

One thing about updating association ids is that they're more susceptible to collisions. For example, let's say an architecture has os_ids [1,2,3]. If user A PUTs os_ids [2,3] and then user B PUTs os_ids [1,2,3,4], then user B will be undoing user A's changes. I don't think this necessarily necessitates add/remove actions but I am wondering if we should worry about solving this now instead of when it could become a problem?

David

···

----- Original Message ----- > From: "Joseph Magen" > To: foreman-dev@googlegroups.com > Sent: Wednesday, January 29, 2014 10:14:35 AM > Subject: Re: [foreman-dev] Updating many-to-many relationships > > One point of clarification referring to the thread that I started on Dec 24 > with subject: Subject: API v2 adding/removing associations: to wrap > parameters or not? > > PUT /architecture/2 > 1) This works - _ids AND WRAPPED > { > "architecture": { > "operatingsystem_ids": [24,25,26] > } > } > > 2) This works - child node and NOT WRAPPED (like GET) > { > "operatingsystems": [{"id": 24},{"id": 25},{"id": 26}] > } > > 3) This does NOT work - child node and WRAPPED > { > "architecture": { > "operatingsystems": [{"id": 24},{"id": 25},{"id": 26}]\ > } > } > > 4) This does NOT work - _ids and NOT WRAPPED > { > "operatingsystem_ids": [24,25,26] > } > > > # 4 is the example that I previously gave, but it current doesn't work. If we > want #3 and #4 to work, then I need to modify > https://github.com/theforeman/foreman/blob/develop/app/controllers/api/v2/base_controller.rb#L59-71 > > > > > ----- Original Message ----- > > From: "Walden Raines" > > To: foreman-dev@googlegroups.com > > Sent: Wednesday, January 29, 2014 4:32:23 PM > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > I like option #3 even better, thanks Joseph. > > > > We may have reached a decision unless there are any dissenting opinions > > that > > remain unvoiced. > > > > Cheers, > > Walden > > > > > > ----- Original Message ----- > > From: "Joseph Magen" > > To: foreman-dev@googlegroups.com > > Sent: Wednesday, January 29, 2014 8:22:11 AM > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > Hi David, > > > > Rails comes out-of-the-box with support for column_names_ids = [1,2,3,4] > > > > Option #3 I created a before_filter in api/v2/base_controller.rb > > > > https://github.com/isratrade/foreman/blob/inherit_loc/app/controllers/api/v2/base_controller.rb#L11 > > > > Basically, I manipulated the input to convert from an array of JSON objects > > to get attribute :column_names_ids = [1,2,3,4] which is what Rails likes in > > the standard `update_attributes` method > > Note, column_names_names = ["name1", "name2"] also works. > > > > Joseph > > > > > > > > ----- Original Message ----- > > > From: "David Davis" > > > To: foreman-dev@googlegroups.com > > > Sent: Wednesday, January 29, 2014 3:13:57 PM > > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > > > Joseph, > > > > > > I'll update the docs when we reach a decision. Question though: how did > > > you > > > all add support for the third option you outlined? Does it comes with > > > Rails? > > > > > > David > > > > > > ----- Original Message ----- > > > > From: "Joseph Magen" > > > > To: foreman-dev@googlegroups.com > > > > Sent: Wednesday, January 29, 2014 2:59:08 AM > > > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > > > > > There's a 3rd option and that is to PUT the JSON response from GET > > > > > > > > GET api/v2/operatingsystems/24 > > > > > > > > Part of the response includes architectures as a child-node > > > > > > > > { > > > > "id": 24, > > > > "name": "CentOs", > > > > "architectures": [ > > > > { > > > > "name": "x86_64", > > > > "id": 1 > > > > } > > > > ] > > > > } > > > > > > > > PUT api/v2/operatingsystems/24 > > > > > > > > And ad another OS in the JSON data > > > > > > > > { > > > > "id": 24, > > > > "name": "CentOs", > > > > "architectures": [ > > > > { > > > > "name": "x86_64", > > > > "id": 1 > > > > }, > > > > { > > > > "name": "i386", > > > > "id": 2 > > > > } > > > > ] > > > > } > > > > > > > > Actually, most of the JSON data above is unnecessary. I can just pass > > > > in > > > > the > > > > relationship node with a collection of ids > > > > > > > > PUT api/v2/operatingsystems/24 > > > > > > > > { > > > > "architectures": [ > > > > { > > > > "id": 1 > > > > }, > > > > { > > > > "id": 2 > > > > } > > > > ] > > > > } > > > > > > > > Note that you can NOT add or remove a SINGLE id as in your option #2. > > > > I > > > > agree with Walden not to implement this. > > > > > > > > Below, this example CREATES a record in has_and_belongs_to_many > > > > relationship > > > > table > > > > > > > > PUT api/v2/operatingsystems/24 > > > > > > > > { > > > > "architectures": [ > > > > { > > > > "id": 1 > > > > }, > > > > { > > > > "id": 2 > > > > } > > > > }, > > > > { > > > > "id": 3 > > > > } > > > > ] > > > > } > > > > > > > > This DELETES a record in has_and_belongs_to_many relationship table > > > > > > > > PUT api/v2/operatingsystems/24 > > > > > > > > { > > > > "architectures": [ > > > > { > > > > "id": 1 > > > > } > > > > ] > > > > } > > > > > > > > > > > > Note that this should work with every has_many or > > > > has_and_belongs_to_many > > > > relationship even if nested routes or child nodes may not appear for in > > > > RABL > > > > templates for all objects. > > > > > > > > > > > > In summary, Foreman supports > > > > #1) Array on attribute operatingsystem_ids on PUT /architecture/2 > > > > > > > > { > > > > "operatingsystem_ids": [24,25,26] > > > > } > > > > > > > > #3) Array on child not operatingsystems PUT /architecture/2 > > > > > > > > { > > > > "operatingsystems": [{"id": 24},{"id": 25},{"id": 26}] > > > > } > > > > > > > > David, I hope this helps. I agree that the documentation needs to be > > > > better. > > > > Can you take the initiative on updating the docs once we reach a final > > > > decision. > > > > > > > > Thanks, > > > > > > > > Joseph > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Walden Raines" > > > > > To: foreman-dev@googlegroups.com > > > > > Sent: Tuesday, January 28, 2014 10:20:15 PM > > > > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > > > > > > > Even though I just followed an existing pattern and implemented a new > > > > > occurrence of #2, I prefer #1 as it is more RESTful. > > > > > > > > > > Cheers, > > > > > Walden > > > > > > > > > > ----- Original Message ----- > > > > > From: "David Davis" > > > > > To: "foreman-dev" > > > > > Sent: Tuesday, January 28, 2014 3:01:29 PM > > > > > Subject: [foreman-dev] Updating many-to-many relationships > > > > > > > > > > So there seems to be a divergence in how Foreman and Katello handle > > > > > many-to-many relationships. To give a couple examples of these, one > > > > > would > > > > > be > > > > > architectures which have and belong to many OSes in Foreman. In > > > > > Katello, > > > > > content views has and belongs to many repositories There 2-3 options > > > > > for > > > > > updating these relationships: > > > > > > > > > > 1. Send in operating_system_ids on PUT /architecture/2 > > > > > 2. Have add_operating_systems and remove_operating_systems actions > > > > > that > > > > > take > > > > > ids > > > > > 3. Both 2 and 3 > > > > > > > > > > Foreman looks like it mostly supports 1 while Katello has a > > > > > combination > > > > > in > > > > > its v2 api of 1 and 2 (but not 3). I can see advantages to all: 1 is > > > > > simpler > > > > > while 2 would maybe be easier to use for the user. 3 seems like a > > > > > good > > > > > option but would be the most work. > > > > > > > > > > Thoughts? > > > > > > > > > > David > > > > > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > > > Groups > > > > > "foreman-dev" group. > > > > > To unsubscribe from this group and stop receiving emails from it, > > > > > send > > > > > an > > > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > > > Groups > > > > > "foreman-dev" group. > > > > > To unsubscribe from this group and stop receiving emails from it, > > > > > send > > > > > an > > > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups > > > > "foreman-dev" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an > > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "foreman-dev" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-dev+unsubscribe@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-dev+unsubscribe@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. >

daviddavis · January 30, 2014, 1:01pm

I meant more RESTful than having separate PUT actions but point taken.

David

···

----- Original Message ----- > From: "Joseph Magen" > To: foreman-dev@googlegroups.com > Sent: Thursday, January 30, 2014 7:48:20 AM > Subject: Re: [foreman-dev] Updating many-to-many relationships > > David, > > You usually don't have a function as a data attribute, even though Rails > generate the *_ids magic methods. It's possible what you suggest although > not RESTful. In fact, to be RESTful, we should not create any NEW objects > with PUT. > > Joseph > > > ----- Original Message ----- > > From: "David Davis" > > To: foreman-dev@googlegroups.com > > Sent: Thursday, January 30, 2014 2:21:43 PM > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > What about something like this? > > > > PUT api/v2/operatingsystems/24 -d {'add_architecture_ids': 1} > > > > Seems like it would be easy to implement, atomic, and RESTful? > > > > David > > > > ----- Original Message ----- > > > From: "Joseph Magen" > > > To: foreman-dev@googlegroups.com > > > Sent: Thursday, January 30, 2014 2:42:10 AM > > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > > > To be specific and atomic, then you need to treat the many-to-many > > > relation > > > as its own resource. This is not the case with our example > > > > > > PUT api/v2/operatingsystems/24 > > > > > > which update all the attributes AND associations for resource operating > > > system #24 > > > > > > The RESTful way to only add or delete an association (similar to what we > > > did > > > for host_classes and hostgroup_classes) is this below: (Note that BOTH > > > the > > > architecture id and operating system id's already exist) > > > > > > Create a new association > > > POST api/v2/operatingsystems/24/architectures_operatingsystems -d {'id': > > > 1} > > > > > > object created > > > { > > > 'id': 555 > > > 'operatingsystem_id': 24 > > > 'architecture_id': 1 > > > } > > > > > > Delete an association > > > DELETE api/v2/operatingsystems/24/architectures_operatingsystems/555 > > > > > > This is similar to what Bryan may thought of when he wrote > > > > > > > What about a > > > > PUT api/v2/operatingsystems/24/architectures > > > > > > But the issue here is that PUT requires an ID of a resource to update. > > > > > > The 'problem' with the atomic restful way is that most 'simple' API's > > > don't > > > expose the database internals such as id #555 on a join table which is > > > meaningless to the user. > > > > > > Regards, > > > > > > Joseph > > > > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Aaron Stone" > > > > To: foreman-dev@googlegroups.com > > > > Sent: Wednesday, January 29, 2014 6:12:10 PM > > > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > > > > > Option #3 is great when you want to rewrite everything, and terrible in > > > > all > > > > other cases. Please allow the minimum edit. GET-modify-PUT has two big > > > > problems: race conditions between editors, and large message size. If > > > > you're trying to edit thingy x with parameter y, an URL to x is very > > > > helpful for being specific and atomic. > > > > > > > > > > > > On Wed, Jan 29, 2014 at 7:48 AM, Bryan Kearney > > > > wrote: > > > > > > > > > What about a > > > > > > > > > > PUT api/v2/operatingsystems/24/architectures > > > > > > > > > > ?? > > > > > > > > > > -- bk > > > > > > > > > > > > > > > On 01/29/2014 02:59 AM, Joseph Magen wrote: > > > > > > > > > >> There's a 3rd option and that is to PUT the JSON response from GET > > > > >> > > > > >> GET api/v2/operatingsystems/24 > > > > >> > > > > >> Part of the response includes architectures as a child-node > > > > >> > > > > >> { > > > > >> "id": 24, > > > > >> "name": "CentOs", > > > > >> "architectures": [ > > > > >> { > > > > >> "name": "x86_64", > > > > >> "id": 1 > > > > >> } > > > > >> ] > > > > >> } > > > > >> > > > > >> PUT api/v2/operatingsystems/24 > > > > >> > > > > >> And ad another OS in the JSON data > > > > >> > > > > >> { > > > > >> "id": 24, > > > > >> "name": "CentOs", > > > > >> "architectures": [ > > > > >> { > > > > >> "name": "x86_64", > > > > >> "id": 1 > > > > >> }, > > > > >> { > > > > >> "name": "i386", > > > > >> "id": 2 > > > > >> } > > > > >> ] > > > > >> } > > > > >> > > > > >> Actually, most of the JSON data above is unnecessary. I can just > > > > >> pass > > > > >> in > > > > >> the relationship node with a collection of ids > > > > >> > > > > >> PUT api/v2/operatingsystems/24 > > > > >> > > > > >> { > > > > >> "architectures": [ > > > > >> { > > > > >> "id": 1 > > > > >> }, > > > > >> { > > > > >> "id": 2 > > > > >> } > > > > >> ] > > > > >> } > > > > >> > > > > >> Note that you can NOT add or remove a SINGLE id as in your option > > > > >> #2. > > > > >> I > > > > >> agree with Walden not to implement this. > > > > >> > > > > >> Below, this example CREATES a record in has_and_belongs_to_many > > > > >> relationship table > > > > >> > > > > >> PUT api/v2/operatingsystems/24 > > > > >> > > > > >> { > > > > >> "architectures": [ > > > > >> { > > > > >> "id": 1 > > > > >> }, > > > > >> { > > > > >> "id": 2 > > > > >> } > > > > >> }, > > > > >> { > > > > >> "id": 3 > > > > >> } > > > > >> ] > > > > >> } > > > > >> > > > > >> This DELETES a record in has_and_belongs_to_many relationship table > > > > >> > > > > >> PUT api/v2/operatingsystems/24 > > > > >> > > > > >> { > > > > >> "architectures": [ > > > > >> { > > > > >> "id": 1 > > > > >> } > > > > >> ] > > > > >> } > > > > >> > > > > >> > > > > >> Note that this should work with every has_many or > > > > >> has_and_belongs_to_many > > > > >> relationship even if nested routes or child nodes may not appear for > > > > >> in > > > > >> RABL templates for all objects. > > > > >> > > > > >> > > > > >> In summary, Foreman supports > > > > >> #1) Array on attribute operatingsystem_ids on PUT /architecture/2 > > > > >> > > > > >> { > > > > >> "operatingsystem_ids": [24,25,26] > > > > >> } > > > > >> > > > > >> #3) Array on child not operatingsystems PUT /architecture/2 > > > > >> > > > > >> { > > > > >> "operatingsystems": [{"id": 24},{"id": 25},{"id": 26}] > > > > >> } > > > > >> > > > > >> David, I hope this helps. I agree that the documentation needs to > > > > >> be > > > > >> better. Can you take the initiative on updating the docs once we > > > > >> reach > > > > >> a > > > > >> final decision. > > > > >> > > > > >> Thanks, > > > > >> > > > > >> Joseph > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> ----- Original Message ----- > > > > >> > > > > >>> From: "Walden Raines" > > > > >>> To: foreman-dev@googlegroups.com > > > > >>> Sent: Tuesday, January 28, 2014 10:20:15 PM > > > > >>> Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > >>> > > > > >>> Even though I just followed an existing pattern and implemented a > > > > >>> new > > > > >>> occurrence of #2, I prefer #1 as it is more RESTful. > > > > >>> > > > > >>> Cheers, > > > > >>> Walden > > > > >>> > > > > >>> ----- Original Message ----- > > > > >>> From: "David Davis" > > > > >>> To: "foreman-dev" > > > > >>> Sent: Tuesday, January 28, 2014 3:01:29 PM > > > > >>> Subject: [foreman-dev] Updating many-to-many relationships > > > > >>> > > > > >>> So there seems to be a divergence in how Foreman and Katello handle > > > > >>> many-to-many relationships. To give a couple examples of these, one > > > > >>> would be > > > > >>> architectures which have and belong to many OSes in Foreman. In > > > > >>> Katello, > > > > >>> content views has and belongs to many repositories There 2-3 > > > > >>> options > > > > >>> for > > > > >>> updating these relationships: > > > > >>> > > > > >>> 1. Send in operating_system_ids on PUT /architecture/2 > > > > >>> 2. Have add_operating_systems and remove_operating_systems actions > > > > >>> that > > > > >>> take > > > > >>> ids > > > > >>> 3. Both 2 and 3 > > > > >>> > > > > >>> Foreman looks like it mostly supports 1 while Katello has a > > > > >>> combination > > > > >>> in > > > > >>> its v2 api of 1 and 2 (but not 3). I can see advantages to all: 1 > > > > >>> is > > > > >>> simpler > > > > >>> while 2 would maybe be easier to use for the user. 3 seems like a > > > > >>> good > > > > >>> option but would be the most work. > > > > >>> > > > > >>> Thoughts? > > > > >>> > > > > >>> David > > > > >>> > > > > >>> -- > > > > >>> You received this message because you are subscribed to the Google > > > > >>> Groups > > > > >>> "foreman-dev" group. > > > > >>> To unsubscribe from this group and stop receiving emails from it, > > > > >>> send > > > > >>> an > > > > >>> email to foreman-dev+unsubscribe@googlegroups.com. > > > > >>> For more options, visit https://groups.google.com/groups/opt_out. > > > > >>> > > > > >>> -- > > > > >>> You received this message because you are subscribed to the Google > > > > >>> Groups > > > > >>> "foreman-dev" group. > > > > >>> To unsubscribe from this group and stop receiving emails from it, > > > > >>> send > > > > >>> an > > > > >>> email to foreman-dev+unsubscribe@googlegroups.com. > > > > >>> For more options, visit https://groups.google.com/groups/opt_out. > > > > >>> > > > > >>> > > > > >> > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > > > Groups > > > > > "foreman-dev" group. > > > > > To unsubscribe from this group and stop receiving emails from it, > > > > > send > > > > > an > > > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups > > > > "foreman-dev" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an > > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "foreman-dev" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-dev+unsubscribe@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. >

Bryan_Kearney · January 30, 2014, 1:31pm

You are correct… but this for me is when the REST WILL SOLVE ALL ISSUES
argument starts to fail. Haveing a resource which is

api/v2/operatingsystems_architectures_relationship

is just nasty in IMHO. I would prefer a POST to
api/v2/operatingsystems/24/architectures which either does a CREATE or
FIND based on the presence of hte ID attribute. But, that is just me

<rant>BTw… I am still waiting for the REST client which actually
parses the url fragments which REST produces to "follow" the api" </rant>

– bk

···

On 01/30/2014 08:19 AM, Joseph Magen wrote: > ----- Original Message ----- >> From: "Bryan Kearney" >> To: foreman-dev@googlegroups.com >> Sent: Thursday, January 30, 2014 3:13:37 PM >> Subject: Re: [foreman-dev] Updating many-to-many relationships >> >> On 01/30/2014 02:42 AM, Joseph Magen wrote: >>> To be specific and atomic, then you need to treat the many-to-many relation >>> as its own resource. This is not the case with our example >>> >>> PUT api/v2/operatingsystems/24 >>> >>> which update all the attributes AND associations for resource operating >>> system #24 >>> >>> The RESTful way to only add or delete an association (similar to what we >>> did for host_classes and hostgroup_classes) is this below: (Note that BOTH >>> the architecture id and operating system id's already exist) >>> >>> Create a new association >>> POST api/v2/operatingsystems/24/architectures_operatingsystems -d {'id': 1} >>> >>> object created >>> { >>> 'id': 555 >>> 'operatingsystem_id': 24 >>> 'architecture_id': 1 >>> } >>> >>> Delete an association >>> DELETE api/v2/operatingsystems/24/architectures_operatingsystems/555 >>> >>> This is similar to what Bryan may thought of when he wrote >>> >>>> What about a >>>> PUT api/v2/operatingsystems/24/architectures >>> >>> But the issue here is that PUT requires an ID of a resource to update. >> >> >> yeah... I should have put POST. >> >>> >>> The 'problem' with the atomic restful way is that most 'simple' API's don't >>> expose the database internals such as id #555 on a join table which is >>> meaningless to the user. >> >> I would make it architectures. That way the join parrt is hidden a bit. > > > POST api/v2/operatingsystems/24/architectures -d {'id': 1} > > This would be confusing, since in RESTful style, a POST on a collection (architectures) creates a new architecture.

Joseph_Magen · January 29, 2014, 3:30pm

Yes, this would be the case. If B puts [1,2,3,4], then it puts back the OS that A deleted.

We do have an example were we POST and DELETE on the join table resource for host classes and hostgroup classes.

github.com

theforeman/foreman/blob/develop/app/controllers/api/v2/host_classes_controller.rb#L16-33


before_action :find_host, :only => [:index, :create, :destroy]


api :GET, "/hosts/:host_id/puppetclass_ids/", N_("List all Puppet class IDs for host")


def index
  render :json => { root_node_name => HostClass.authorized(:edit_classes).where(:host_id => @host.id).pluck('puppetclass_id') }
end


api :POST, "/hosts/:host_id/puppetclass_ids", N_("Add a Puppet class to host")
param :host_id, String, :required => true, :desc => N_("ID of host")
param :puppetclass_id, String, :required => true, :desc => N_("ID of Puppet class")


def create
  @host_class = HostClass.create!(:host_id => @host.id, :puppetclass_id => params[:puppetclass_id].to_i)
  render :json => {:host_id => @host_class.host_id, :puppetclass_id => @host_class.puppetclass_id}
end


api :DELETE, "/hosts/:host_id/puppetclass_ids/:id/", N_("Remove a Puppet class from host")
param :host_id, String, :required => true, :desc => N_("ID of host")
param :id, String, :required => true, :desc => N_("ID of Puppet class")

We renamed the paths to puppetclass_ids

github.com

theforeman/foreman/blob/develop/config/routes/api/v2.rb#L177




resources :config_reports, :only => [:index, :show, :destroy] do
  get :last, :on => :collection
end


resources :roles, :except => [:new, :edit] do
  resources :filters, :except => [:new, :edit] do
    (resources :locations, :only => [:index, :show]) if SETTINGS[:locations_enabled]
    (resources :organizations, :only => [:index, :show]) if SETTINGS[:organizations_enabled]
  end
  resources :users, :except => [:new, :edit]
  member do
    post :clone
  end
end
resources :permissions, :only => [:index, :show] do
  collection do
    get :resource_types
  end
end

However, I'm not convinced this should be done for every has has_and_belongs_to_many relationship. And btw, it can't be done on regular has_many relationships.

Joseph

···

----- Original Message ----- > From: "David Davis" > To: foreman-dev@googlegroups.com > Sent: Wednesday, January 29, 2014 5:21:54 PM > Subject: Re: [foreman-dev] Updating many-to-many relationships > > One thing about updating association ids is that they're more susceptible to > collisions. For example, let's say an architecture has os_ids [1,2,3]. If > user A PUTs os_ids [2,3] and then user B PUTs os_ids [1,2,3,4], then user B > will be undoing user A's changes. I don't think this necessarily > necessitates add/remove actions but I am wondering if we should worry about > solving this now instead of when it could become a problem? > > David > > ----- Original Message ----- > > From: "Joseph Magen" > > To: foreman-dev@googlegroups.com > > Sent: Wednesday, January 29, 2014 10:14:35 AM > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > One point of clarification referring to the thread that I started on Dec 24 > > with subject: Subject: API v2 adding/removing associations: to wrap > > parameters or not? > > > > PUT /architecture/2 > > 1) This works - _ids AND WRAPPED > > { > > "architecture": { > > "operatingsystem_ids": [24,25,26] > > } > > } > > > > 2) This works - child node and NOT WRAPPED (like GET) > > { > > "operatingsystems": [{"id": 24},{"id": 25},{"id": 26}] > > } > > > > 3) This does NOT work - child node and WRAPPED > > { > > "architecture": { > > "operatingsystems": [{"id": 24},{"id": 25},{"id": 26}]\ > > } > > } > > > > 4) This does NOT work - _ids and NOT WRAPPED > > { > > "operatingsystem_ids": [24,25,26] > > } > > > > > > # 4 is the example that I previously gave, but it current doesn't work. If > > we > > want #3 and #4 to work, then I need to modify > > https://github.com/theforeman/foreman/blob/develop/app/controllers/api/v2/base_controller.rb#L59-71 > > > > > > > > > > ----- Original Message ----- > > > From: "Walden Raines" > > > To: foreman-dev@googlegroups.com > > > Sent: Wednesday, January 29, 2014 4:32:23 PM > > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > > > I like option #3 even better, thanks Joseph. > > > > > > We may have reached a decision unless there are any dissenting opinions > > > that > > > remain unvoiced. > > > > > > Cheers, > > > Walden > > > > > > > > > ----- Original Message ----- > > > From: "Joseph Magen" > > > To: foreman-dev@googlegroups.com > > > Sent: Wednesday, January 29, 2014 8:22:11 AM > > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > > > Hi David, > > > > > > Rails comes out-of-the-box with support for column_names_ids = [1,2,3,4] > > > > > > Option #3 I created a before_filter in api/v2/base_controller.rb > > > > > > https://github.com/isratrade/foreman/blob/inherit_loc/app/controllers/api/v2/base_controller.rb#L11 > > > > > > Basically, I manipulated the input to convert from an array of JSON > > > objects > > > to get attribute :column_names_ids = [1,2,3,4] which is what Rails likes > > > in > > > the standard `update_attributes` method > > > Note, column_names_names = ["name1", "name2"] also works. > > > > > > Joseph > > > > > > > > > > > > ----- Original Message ----- > > > > From: "David Davis" > > > > To: foreman-dev@googlegroups.com > > > > Sent: Wednesday, January 29, 2014 3:13:57 PM > > > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > > > > > Joseph, > > > > > > > > I'll update the docs when we reach a decision. Question though: how did > > > > you > > > > all add support for the third option you outlined? Does it comes with > > > > Rails? > > > > > > > > David > > > > > > > > ----- Original Message ----- > > > > > From: "Joseph Magen" > > > > > To: foreman-dev@googlegroups.com > > > > > Sent: Wednesday, January 29, 2014 2:59:08 AM > > > > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > > > > > > > There's a 3rd option and that is to PUT the JSON response from GET > > > > > > > > > > GET api/v2/operatingsystems/24 > > > > > > > > > > Part of the response includes architectures as a child-node > > > > > > > > > > { > > > > > "id": 24, > > > > > "name": "CentOs", > > > > > "architectures": [ > > > > > { > > > > > "name": "x86_64", > > > > > "id": 1 > > > > > } > > > > > ] > > > > > } > > > > > > > > > > PUT api/v2/operatingsystems/24 > > > > > > > > > > And ad another OS in the JSON data > > > > > > > > > > { > > > > > "id": 24, > > > > > "name": "CentOs", > > > > > "architectures": [ > > > > > { > > > > > "name": "x86_64", > > > > > "id": 1 > > > > > }, > > > > > { > > > > > "name": "i386", > > > > > "id": 2 > > > > > } > > > > > ] > > > > > } > > > > > > > > > > Actually, most of the JSON data above is unnecessary. I can just > > > > > pass > > > > > in > > > > > the > > > > > relationship node with a collection of ids > > > > > > > > > > PUT api/v2/operatingsystems/24 > > > > > > > > > > { > > > > > "architectures": [ > > > > > { > > > > > "id": 1 > > > > > }, > > > > > { > > > > > "id": 2 > > > > > } > > > > > ] > > > > > } > > > > > > > > > > Note that you can NOT add or remove a SINGLE id as in your option #2. > > > > > I > > > > > agree with Walden not to implement this. > > > > > > > > > > Below, this example CREATES a record in has_and_belongs_to_many > > > > > relationship > > > > > table > > > > > > > > > > PUT api/v2/operatingsystems/24 > > > > > > > > > > { > > > > > "architectures": [ > > > > > { > > > > > "id": 1 > > > > > }, > > > > > { > > > > > "id": 2 > > > > > } > > > > > }, > > > > > { > > > > > "id": 3 > > > > > } > > > > > ] > > > > > } > > > > > > > > > > This DELETES a record in has_and_belongs_to_many relationship table > > > > > > > > > > PUT api/v2/operatingsystems/24 > > > > > > > > > > { > > > > > "architectures": [ > > > > > { > > > > > "id": 1 > > > > > } > > > > > ] > > > > > } > > > > > > > > > > > > > > > Note that this should work with every has_many or > > > > > has_and_belongs_to_many > > > > > relationship even if nested routes or child nodes may not appear for > > > > > in > > > > > RABL > > > > > templates for all objects. > > > > > > > > > > > > > > > In summary, Foreman supports > > > > > #1) Array on attribute operatingsystem_ids on PUT /architecture/2 > > > > > > > > > > { > > > > > "operatingsystem_ids": [24,25,26] > > > > > } > > > > > > > > > > #3) Array on child not operatingsystems PUT /architecture/2 > > > > > > > > > > { > > > > > "operatingsystems": [{"id": 24},{"id": 25},{"id": 26}] > > > > > } > > > > > > > > > > David, I hope this helps. I agree that the documentation needs to be > > > > > better. > > > > > Can you take the initiative on updating the docs once we reach a > > > > > final > > > > > decision. > > > > > > > > > > Thanks, > > > > > > > > > > Joseph > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Walden Raines" > > > > > > To: foreman-dev@googlegroups.com > > > > > > Sent: Tuesday, January 28, 2014 10:20:15 PM > > > > > > Subject: Re: [foreman-dev] Updating many-to-many relationships > > > > > > > > > > > > Even though I just followed an existing pattern and implemented a > > > > > > new > > > > > > occurrence of #2, I prefer #1 as it is more RESTful. > > > > > > > > > > > > Cheers, > > > > > > Walden > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "David Davis" > > > > > > To: "foreman-dev" > > > > > > Sent: Tuesday, January 28, 2014 3:01:29 PM > > > > > > Subject: [foreman-dev] Updating many-to-many relationships > > > > > > > > > > > > So there seems to be a divergence in how Foreman and Katello handle > > > > > > many-to-many relationships. To give a couple examples of these, one > > > > > > would > > > > > > be > > > > > > architectures which have and belong to many OSes in Foreman. In > > > > > > Katello, > > > > > > content views has and belongs to many repositories There 2-3 > > > > > > options > > > > > > for > > > > > > updating these relationships: > > > > > > > > > > > > 1. Send in operating_system_ids on PUT /architecture/2 > > > > > > 2. Have add_operating_systems and remove_operating_systems actions > > > > > > that > > > > > > take > > > > > > ids > > > > > > 3. Both 2 and 3 > > > > > > > > > > > > Foreman looks like it mostly supports 1 while Katello has a > > > > > > combination > > > > > > in > > > > > > its v2 api of 1 and 2 (but not 3). I can see advantages to all: 1 > > > > > > is > > > > > > simpler > > > > > > while 2 would maybe be easier to use for the user. 3 seems like a > > > > > > good > > > > > > option but would be the most work. > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > David > > > > > > > > > > > > -- > > > > > > You received this message because you are subscribed to the Google > > > > > > Groups > > > > > > "foreman-dev" group. > > > > > > To unsubscribe from this group and stop receiving emails from it, > > > > > > send > > > > > > an > > > > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > > > -- > > > > > > You received this message because you are subscribed to the Google > > > > > > Groups > > > > > > "foreman-dev" group. > > > > > > To unsubscribe from this group and stop receiving emails from it, > > > > > > send > > > > > > an > > > > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > > > Groups > > > > > "foreman-dev" group. > > > > > To unsubscribe from this group and stop receiving emails from it, > > > > > send > > > > > an > > > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups > > > > "foreman-dev" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an > > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "foreman-dev" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "foreman-dev" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-dev+unsubscribe@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. >

Tomas_Strachota · February 5, 2014, 10:00am

>>> From: "Bryan Kearney" <bryan.kearney@gmail.com>
>>> To: foreman-dev@googlegroups.com
>>> Sent: Thursday, January 30, 2014 3:13:37 PM
>>> Subject: Re: [foreman-dev] Updating many-to-many relationships
>>>
>>>> To be specific and atomic, then you need to treat the many-to-many
>>>> relation
>>>> as its own resource. This is not the case with our example
>>>>
>>>> PUT api/v2/operatingsystems/24
>>>>
>>>> which update all the attributes AND associations for resource operating
>>>> system #24
>>>>
>>>> The RESTful way to only add or delete an association (similar to
>>>> what we
>>>> did for host_classes and hostgroup_classes) is this below: (Note
>>>> that BOTH
>>>> the architecture id and operating system id's already exist)
>>>>
>>>> Create a new association
>>>> POST api/v2/operatingsystems/24/architectures_operatingsystems -d
>>>> {'id': 1}
>>>>
>>>> object created
>>>> {
>>>> 'id': 555
>>>> 'operatingsystem_id': 24
>>>> 'architecture_id': 1
>>>> }
>>>>
>>>> Delete an association
>>>> DELETE api/v2/operatingsystems/24/architectures_operatingsystems/555
>>>>
>>>> This is similar to what Bryan may thought of when he wrote
>>>>
>>>>> What about a
>>>>> PUT api/v2/operatingsystems/24/architectures
>>>>
>>>> But the issue here is that PUT requires an ID of a resource to update.
>>>
>>>
>>> yeah… I should have put POST.
>>>
>>>>
>>>> The 'problem' with the atomic restful way is that most 'simple'
>>>> API's don't
>>>> expose the database internals such as id #555 on a join table which is
>>>> meaningless to the user.
>>>
>>> I would make it architectures. That way the join parrt is hidden a bit.
>>
>>
>> POST api/v2/operatingsystems/24/architectures -d {'id': 1}
>>
>> This would be confusing, since in RESTful style, a POST on a
>> collection (architectures) creates a new architecture.
>
>
> You are correct… but this for me is when the REST WILL SOLVE ALL ISSUES
> argument starts to fail. Haveing a resource which is
>
> api/v2/operatingsystems_architectures_relationship
>
> is just nasty in IMHO. I would prefer a POST to
> api/v2/operatingsystems/24/architectures which either does a CREATE or
> FIND based on the presence of hte ID attribute. But, that is just me

+1

Even though it might be confusing I tend to agree with what Bryan
described. Sending all remaining associated ids every time I want to add
another one is not very pleasant.

···

On 01/30/2014 02:31 PM, Bryan Kearney wrote: > On 01/30/2014 08:19 AM, Joseph Magen wrote: >> ----- Original Message ----- >>> On 01/30/2014 02:42 AM, Joseph Magen wrote:

BTw… I am still waiting for the REST client which actually
parses the url fragments which REST produces to “follow” the api"

– bk