Skip to content
This repository has been archived by the owner on Mar 11, 2021. It is now read-only.

Restrict iterating over every workitem field for reorder #2261

Closed

Conversation

DhritiShikhar
Copy link
Contributor

@DhritiShikhar DhritiShikhar commented Aug 28, 2018

@alien-ike
Copy link

alien-ike commented Aug 28, 2018

Ike Plugins (test-keeper)

Thank you @DhritiShikhar for this contribution!

It seems that this PR already contains some added or changed tests. Good job!

For more information please head over to official documentation. You can find there how to configure the plugin.

@codecov-io
Copy link

codecov-io commented Aug 28, 2018

Codecov Report

Merging #2261 into master will increase coverage by 1.84%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2261      +/-   ##
==========================================
+ Coverage   69.53%   71.37%   +1.84%     
==========================================
  Files         176      176              
  Lines       16670    17818    +1148     
==========================================
+ Hits        11591    12718    +1127     
+ Misses       3956     3940      -16     
- Partials     1123     1160      +37
Impacted Files Coverage Δ
workitem/workitem_repository.go 71.33% <100%> (+3.64%) ⬆️
controller/user.go 34.04% <0%> (-4.99%) ⬇️
migration/migration.go 61.11% <0%> (-0.46%) ⬇️
controller/space_iterations.go 84.78% <0%> (+0.51%) ⬆️
controller/area.go 92.78% <0%> (+0.52%) ⬆️
controller/iteration.go 81.12% <0%> (+2.79%) ⬆️
workitem/expression_compiler.go 87.29% <0%> (+3.79%) ⬆️
path/path.go 71.42% <0%> (+4.76%) ⬆️
controller/space.go 74.67% <0%> (+4.83%) ⬆️
... and 4 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a8fab53...a37aad6. Read the comment docs.

@DhritiShikhar DhritiShikhar changed the title WIP: restrict iterating over every workitem field for reorder Restrict iterating over every workitem field for reorder Aug 28, 2018
@DhritiShikhar
Copy link
Contributor Author

[test]

originalTitle := "Original Title"
payload.Data.Attributes[workitem.SystemTitle] = originalTitle
payload.Data.Attributes[workitem.SystemState] = workitem.SystemStateClosed
_, workitem1 := test.CreateWorkitemsCreated(s.T(), s.svc.Context, s.svc, s.workitemsCtrl, *payload.Data.Relationships.Space.Data.ID, &payload)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can use test fixture to create the initial work item. That would remove all the code from line 566 to 576

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jarifibrahim The test fixture gives me a workitem of workitem.Workitem type but I need app.WorkItem to create reorder payload.

}
}
tx = tx.Where("Version = ?", wi.Version).Save(&res)
tx = tx.Model(&res).Where("Version = ?", wi.Version).UpdateColumns(WorkItemStorage{ExecutionOrder: order, Version: res.Version + 1})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't we use update() instead of updateColumns ?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DhritiShikhar @jarifibrahim

When reading the gorm docs I found this:

Above updating operations will perform the model's BeforeUpdate, AfterUpdate method, update its UpdatedAt timestamp, save its Associations when updaing, if you don't want to call them, you could use UpdateColumn, UpdateColumns.

(source: http://doc.gorm.io/crud.html#update)

We certainly want to call all those functions so UpdateColumn and UpdateColumns are not an option for us to use.

Probably the safest way to update the columns is using this syntax:

tx = tx.Model(WorkItemStorage{Version:wi.Version}).Select("version").Select("execution_order").Updates(map[string]interface{}{
  "execution_order": order,
  "version": res.Version + 1,
})

Notice that by using Model() as I did we don't need the Where function anymore.

What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kwk I am not completely sure how this works

tx = tx.Model(WorkItemStorage{Version:wi.Version}).Select("version").Select("execution_order").Updates(map[string]interface{}{
  "execution_order": order,
  "version": res.Version + 1,
})

I couldn't find examples like tx.Model(WorkItemStorage{Version:wi.Version}) . Is it equivalent to select .. where version = wi.Version?

dataArray = append(dataArray, workitem1.Data)
payload2.Data = dataArray
payload2.Position.ID = workitem2.Data.ID // Position.ID specifies the workitem ID above or below which the workitem(s) should be placed
payload2.Position.Direction = string(workitem.DirectionAbove)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

workitem.DirectionAbove is already a string, you don't need the string(...)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

workitem.DirectionAbove is workitem.DirectionType

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but workitem.DirectionType is of type string
See https://play.golang.org/p/Nov7b0810R-

package main

import (
	"fmt"
)

func main() {
	type direction string
	const foo direction = "above"
	bar := foo
	fmt.Println(foo, bar)
}


payload2 := minimumRequiredReorderPayload()

var dataArray []*app.WorkItem // dataArray contains the workitem(s) that have to be reordered
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can also be removed when fxt.Workitems[] is used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jarifibrahim The test fixture gives me a workitem of workitem.Workitem type but I need app.WorkItem to create reorder payload.

assert.Equal(s.T(), workitem1.Data.Attributes["version"].(int)+1, reorderedList.Data[0].Attributes["version"])
assert.Equal(s.T(), *workitem1.Data.ID, *reorderedList.Data[0].ID)
assert.NotEqual(s.T(), titleNotUpdated, reorderedList.Data[0].Attributes[workitem.SystemTitle])
assert.Equal(s.T(), originalTitle, reorderedList.Data[0].Attributes[workitem.SystemTitle])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed here adccee4

}
}
tx = tx.Where("Version = ?", wi.Version).Save(&res)
tx = tx.Model(&res).Where("Version = ?", wi.Version).UpdateColumns(WorkItemStorage{ExecutionOrder: order, Version: res.Version + 1})
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DhritiShikhar @jarifibrahim

When reading the gorm docs I found this:

Above updating operations will perform the model's BeforeUpdate, AfterUpdate method, update its UpdatedAt timestamp, save its Associations when updaing, if you don't want to call them, you could use UpdateColumn, UpdateColumns.

(source: http://doc.gorm.io/crud.html#update)

We certainly want to call all those functions so UpdateColumn and UpdateColumns are not an option for us to use.

Probably the safest way to update the columns is using this syntax:

tx = tx.Model(WorkItemStorage{Version:wi.Version}).Select("version").Select("execution_order").Updates(map[string]interface{}{
  "execution_order": order,
  "version": res.Version + 1,
})

Notice that by using Model() as I did we don't need the Where function anymore.

What do you think?

@DhritiShikhar
Copy link
Contributor Author

@kwk

I use updates instead of updateColumns

tx = tx.Model(&res).Select("execution_order", "version").Updates(WorkItemStorage{
		ExecutionOrder: order,
		Version:        res.Version + 1,
	})

tx.Model(WorkItemStorage{Version:wi.Version}) doesnot update execution order so still using tx.Model(&res)

@DhritiShikhar
Copy link
Contributor Author

[test]

@DhritiShikhar
Copy link
Contributor Author

[test]

}
}
tx = tx.Where("Version = ?", wi.Version).Save(&res)
tx = tx.Model(&res).Select("execution_order", "version").Updates(WorkItemStorage{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why doesn't this have a where clause?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because I pass .Model instead of .Where

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DhritiShikhar can you please show the .Debug(). output of this query? I think Gorm only checks for the primary key if you do .Model(&res).. And the version is not the primary field.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Restrict iterating over every workitem field during reorder
5 participants