feat: Add missing fields to EfUser model
Merged
requested to merge zacharysabourin/eclipsefdn-api-common:zacharysabourin/main/add-missing-efuser-fields into main
1 unresolved thread
Compare changes
Files
5@@ -23,15 +23,14 @@ import com.fasterxml.jackson.databind.annotation.JsonPOJOBuilder;
@@ -23,15 +23,14 @@ import com.fasterxml.jackson.databind.annotation.JsonPOJOBuilder;
@@ -63,7 +62,7 @@ public abstract class EfUser {
@@ -63,7 +62,7 @@ public abstract class EfUser {
@@ -76,6 +75,18 @@ public abstract class EfUser {
@@ -76,6 +75,18 @@ public abstract class EfUser {
@@ -105,8 +116,9 @@ public abstract class EfUser {
@@ -105,8 +116,9 @@ public abstract class EfUser {
@@ -117,11 +129,16 @@ public abstract class EfUser {
@@ -117,11 +129,16 @@ public abstract class EfUser {
@@ -132,7 +149,7 @@ public abstract class EfUser {
@@ -132,7 +149,7 @@ public abstract class EfUser {
@@ -158,7 +175,7 @@ public abstract class EfUser {
@@ -158,7 +175,7 @@ public abstract class EfUser {
@@ -170,6 +187,13 @@ public abstract class EfUser {
@@ -170,6 +187,13 @@ public abstract class EfUser {
@@ -196,8 +220,7 @@ public abstract class EfUser {
@@ -196,8 +220,7 @@ public abstract class EfUser {
This is a breaking change that will be kind of annoying to fix in our various tests. Is there a reason we're switching types here? From what I understand this will always be a number so it shouldn't be a problem
I'm matching the return from D7. It's technically a String and shouldn't have been an int at all
Technically a string, in that drupal doesn't return non-string types. It is functionally a number in the system as the nid is always a number though. Jackson should be able to handle conversions for us to make the values more accurate if we need it
Drupal can return numbers.
org_id
is returned as an int from D7.Ex: https://api.eclipse.org/account/profile/mmilinkovich
I stand corrected on that part of my point, I hadn't realized that as I haven't looked at the raw of that output in a while. The other point still stands though, the nid from Drupal is a serial column and is still a number in Drupal 9 as well.
Our models don't have to be perfect replicas of the data, just useful representations of them. Does the type switch fix something or improve usability by making this change? If this didn't create as many breaking changes as it does, I wouldn't mind, but this would affect a lot of packages for no gain that I can see
I'd argue that if any consumers of this API would be expecting a string, it will likely break for them when it goes live as an int.
The org id is also changing to an int, wouldn't that also be a breaking change for our other APIs?