# Add/Remove OneToMany collection items w/o persisting?

**URL:** <https://www.ruby-forum.com/t/add-remove-onetomany-collection-items-w-o-persisting/104788>\
**Category:** Rails\
**Created:** [May 22, 2007, 4:33pm UTC](https://www.ruby-forum.com/t/add-remove-onetomany-collection-items-w-o-persisting/104788 "2007-05-22T16:33:36Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![dennis](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/e56c9b/32.png) [@dennis](https://www.ruby-forum.com/u/dennis)\
**Post date:** [May 22, 2007, 4:33pm UTC](https://www.ruby-forum.com/t/add-remove-onetomany-collection-items-w-o-persisting/104788/1 "2007-05-22T16:33:36Z")

</div>

Ok. Case. I have one duck, which has many ducklings… Some of these  
ducklings ceases to exist (dies) or duck gives birth to new ducklings…

However… A duckling is not an empty entity. There are some constraints  
in the db which we must conform to. So. Whenever a duck dies or new ones  
gets born, details needs to be provided before we actually want to  
persist it to the database. So i can’t do:

@duck = Duck.find(:first)  
@duck.ducklings \<\< Duck.new

…since i’ve observed that the new duck is persisted right away. This  
violates some constraints and i do not want to persist the duck yet.  
Furthermore. A duck usually gives birth to more than one duckling at a  
time, so we want to manipulate a lot of ducklings from the same form at  
the same time. If i remove a duckling, if i add a duckling or if i alter  
a duckling’s information, i first want this to be persisted when i hit  
update.

Now this has caused me some issues…

Loading the duck and listing form rows for duck.ducklings gives me text  
fields with: ducklings[1][name], ducklings[1][birth\_date]… That is.  
Form submitted back is translated into a hash with key matching the db  
id…

However. Now i click add and a new row is created via RJS from a new  
instance of Duckling… However. Since this is not persisted, i’ll now  
have a row-field with id: ducklings[][name]… Hitting update will now  
cause an application error:

Conflicting types for parameter containers. Expected an instance of  
Array, but found an instance of Hash. This can be caused by passing  
Array and Hash based paramters qs[]=value&qs[key]=value.

Well. I do understand the error message, however. Expected rails to have  
some magic in this sense giving me a cleaner view, such that non-keyed  
entries were treated as new entries thus would yield a save instead of  
update.

Do i really have to distinguish new from existing entries by alternative  
field names? Aren’t there any prettier ways to do this?

Haven’t been able to find anyone discussing this particular issue… What  
is the rails way? 🙂 I’d really like that new and old persisted entries  
came back in the same params collection in some way.

---

<div class="post-metadata">

**Author:** ![dennis](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/e56c9b/32.png) [@dennis](https://www.ruby-forum.com/u/dennis)\
**Post date:** [May 22, 2007, 5:58pm UTC](https://www.ruby-forum.com/t/add-remove-onetomany-collection-items-w-o-persisting/104788/2 "2007-05-22T17:58:49Z")

</div>

A few thoughts:

The first thing is to understand when Rails will automatically persist  
records. In a 1:n relationship where a Duck has\_many Ducklings and a  
Duckling belongs\_to Duck, the foreign key is stored in the Duckling.  
If you assign a Duckling to Duck it will persist it right away because  
it assumes you are working on the Duck and their is just a single  
change to the Duckling that must be saved right away. If you want to  
make the association without saving, you assign @duckling.duck\_id =  
@duck.id because that appears you are primarily editing the Duckling  
and will manage your own saving. The first scenario is really just a  
convience since you would have to individually save all the ducklings  
anyway, and if you forget, Rails has no efficient way of remember  
which to save when you do @duck.save.

Regarding your second scenario, there is no magic I’m afraid. I could  
definitely see some improvements being made to support this kind of  
thing, but ultimately I think you can roll something up that’s pretty  
clean.

The first thing is the whole concept of objects[][name]&objects[][age]  
is failed even in the absence of a conflicting hash because there’s no  
way to keep the groups coherent. I suppose this could be fixed as  
long as you can guarantee the presence of every field (been burned by  
checkboxes in this situation in PHP). But really if you have more  
than one, you need to index them somehow.

So you can stick your own index in there to make it a hash. But you  
will also need to distinguish the new from the updates. So it should  
have a different name such as new\_ducklings[0], new\_ducklings[1].  
Then you can create a new\_ducklings=(hash) method on the Duck model  
that processes these accordingly.

However, if you are just adding one at a time using RJS, you can just  
skip the whole index, and have a plain new\_duckling hash of fields.

Hopefully that will help a bit. It’s definitely not a trivial  
problem.