Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add multi object test #87

Merged
merged 18 commits into from
May 29, 2018
Merged

Add multi object test #87

merged 18 commits into from
May 29, 2018

Conversation

mrobustelli
Copy link
Contributor

I know there are some tab and spacing redos, but I am now using the extension Avi recommended. The Write test does not pass yet, but I will work on both single and multi object write tests next.

yield return new TestCaseData("SingleChoice", SingleChoiceFieldChoices.SingleChoice2);
yield return new TestCaseData("GravityLevel2Obj", new GravityLevel2() { Name = "Test_" + Guid.NewGuid() });
yield return new TestCaseData("GravityLevel2MultipleObjs", new List<GravityLevel2>(){
new GravityLevel2()
Copy link
Collaborator

Choose a reason for hiding this comment

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

Consider using a LINQ statement to get this done. Something like

Enumerable.Range(1,3).Select(_ => new GravityLevel2	{ Name = "Test_" + Guid.NewGuid() }).ToList()

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done, will look at moving these test cases in RSAPI_IntegrationTests.cs and you have with the other unit tests in another PR.

Copy link
Collaborator

@Arithmomaniac Arithmomaniac left a comment

Choose a reason for hiding this comment

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

I haven't looked at the actual test code yet, but the changes based on the wrong lines being removed from GravityLevelOne.cs need to be undone.

@@ -34,15 +34,9 @@ public class GravityLevelOne : BaseDto
public RelativityFile FileField { get; set; }

[RelativityObjectField("D0770889-8A4D-436A-9647-33419B96E37E", RdoFieldType.MultipleObject, typeof(GravityLevel2))]
public IList<int> GravityLevel2MultipleArtifactIds { get; set; }

[RelativityMultipleObject("D0770889-8A4D-436A-9647-33419B96E37E")]
Copy link
Collaborator

Choose a reason for hiding this comment

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

These are the wrong removed attributes, no? The types on the remaining object versions should stay as is (RelativityMultipleObject, RelativitySingleObject).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

At first that is the route I took, but when I looked at it, there is no real need to the single objects and multiple object as anything other than a different field type. I have a feeling child object will be similar. This is much easier for the consumer. One way to define all the fields.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Well, child object can't be similar, because it doesn't even have a field definition.

As for single/multiple, the idea is that you don't need to declare the type because it can be inferred. Perhaps we should remove the type argument on RelativityObjectField altogether, now that we don't have the ID-list versions.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I realized I need to update the Readme file as well. Will do that in another PR

Copy link
Collaborator

Choose a reason for hiding this comment

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

Why another one? If you're changing the contract, you should do it in this one.

Similarly, I think this PR should remove the ObjectFieldDTOType attribute, as mentioned in a previous comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Why another one? I was trying to rush to get this done, but you are right. I updated the readme.

As far as the remove ObjectFieldDTOType...I think that should be done. However I would like to save that for another PR. I will create an issue for it.

gravityFieldValue = (gravityFieldValue as GravityLevel2).Name;
break;
case RdoFieldType.MultipleObject:
var resultsDictionary = new Dictionary<int, string>();
Copy link
Collaborator

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.

you and Linq? I gotta admit, it's starting to grow on me a bit. Done.

@Arithmomaniac
Copy link
Collaborator

The now-unused RelativityMultipleObject and RelativitySingleObject attributes should be deleted.

Copy link
Collaborator

@Arithmomaniac Arithmomaniac left a comment

Choose a reason for hiding this comment

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

I really like this; much simpler! Just a few changes suggested (I had extra time allotted to day on Gravity 😉)

Also see these comments:
#87 (comment)
#87 (comment)

@@ -187,7 +137,15 @@ private static object ConvertPropertyValue(PropertyInfo property, RdoFieldType f
case RdoFieldType.MultipleObject:
{
return new FieldValueList<Artifact>(
((IList<int>)propertyValue).Select(x => new Artifact(x)));
(
Copy link
Collaborator

Choose a reason for hiding this comment

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

Cast objects to BaseDto instead of using reflection (yes, this issue preceded you). Also align parentheses better

Copy link
Contributor Author

Choose a reason for hiding this comment

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

very good call. I had the same thought about reflection being expensive and taking a pass through the code looking for ways to optimize or potentially using caching or something. No need to continue to contribute to the problem. Done

@@ -202,9 +160,11 @@ private static object ConvertPropertyValue(PropertyInfo property, RdoFieldType f

case RdoFieldType.SingleObject:
{
if ((int)propertyValue > 0)
int artifactId = (int)propertyValue.GetType().GetProperty("ArtifactId")?.GetValue(propertyValue, null);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Cast object to BaseDto instead of using reflection (yes, this issue preceded you).

@@ -118,13 +120,15 @@ internal void PopulateChildrenRecursively<T>(BaseDto baseDto, RDO objectRdo, Obj

private object GetChildObjectRecursively(BaseDto baseDto, RDO objectRdo, ObjectFieldsDepthLevel depthLevel, PropertyInfo property)
{
var fieldType = property.GetCustomAttribute<RelativityObjectFieldAttribute>()?.FieldType;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Instead of this, try and find the RelativityObjectFieldAttribute and wrap the next two blocks in an "if not null" statement. We shouldn't be looking up the attribute twice in a row (reflection is expensive), and it better communicates intent (the FieldGuid can never be null when the field type is set).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

private bool InsertUpdateSingleObjectFields(BaseDto objectToInsert)
{
foreach (var propertyInfo in objectToInsert.GetType().GetProperties().Where(c =>
c.GetCustomAttribute<RelativityObjectFieldAttribute>()?.FieldType == RdoFieldType.SingleObject))
Copy link
Collaborator

Choose a reason for hiding this comment

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

Don't query for the attribute twice. Try and find it, and move on if it is null

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@Arithmomaniac Not sure what you mean here? I need to get all the SingleObject field types, then do stuff with those fields. Suggestions requested for clarity.

Copy link
Collaborator

Choose a reason for hiding this comment

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

foreach (var propertyInfo in objectToInsert.GetType().GetProperties())
{
	var attribute = propertyInfo.GetCustomAttribute<RelativityObjectFieldAttribute>();
	if (attribute?.FieldType == RdoFieldType.SingleObject)
	{
		var fieldValue = (BaseDto)objectToInsert.GetPropertyValue(propertyInfo.Name);
		if (fieldValue != null)
		{
			var fieldGuid = attribute.FieldGuid;
			//...
		}
	}
}

c.GetCustomAttribute<RelativityObjectFieldAttribute>()?.FieldType == RdoFieldType.SingleObject))
{
var fieldGuid = propertyInfo.GetCustomAttribute<RelativityObjectFieldAttribute>()?.FieldGuid;
var fieldValue = (objectToInsert.GetPropertyValue(propertyInfo.Name) as BaseDto);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Cast instead of using as

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done


if (fieldGuid != null && fieldValue != null)
{
//TODO: better test to see if contains value...if all fields are null, not need
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'd insert it anyways; expected behavior is to insert an object if you ask for it (no different than, say, what would happen with RSAPI today).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good logical thinking as always. Cleaned it up.

}
else
{
//TODO: Consider update if fields have changed
Copy link
Collaborator

Choose a reason for hiding this comment

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

If we're not updating for now, I would just name the base method InsertSingleObjectFields.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

}

public int InsertRelativityObject<T>(BaseDto theObjectToInsert)
private bool InsertUpdateMultipleObjectFields(BaseDto objectToInsert)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Comments above apply here too

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

{
foreach (var childObject in fieldValue)
{
if (fieldGuid != null && fieldValue != null)
Copy link
Collaborator

Choose a reason for hiding this comment

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

This check is redundant

…ect changes. Also cleand up code from code comments.
@mrobustelli
Copy link
Contributor Author

Good suggestions as usual. Made most of them. The only open item from comments is the multiple query stuff around Insert.cs around line 130.

@mrobustelli
Copy link
Contributor Author

@Arithmomaniac, didn't see your latest comment last week for some reason. Thanks for posting. The latest commit cleans up the last of this round of comments. Should be good to go here.

@mrobustelli mrobustelli merged commit a4d83d5 into development May 29, 2018
@mrobustelli mrobustelli deleted the AddMultiObjectTest branch May 29, 2018 17:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants