Details

    • Task
    • Status: Open
    • Minor
    • Resolution: Unresolved
    • None
    • None
    • None

    Description

      External Reference Code

      RIGHT NOW:

      Add -> ERC first

      e.g. public CommerceDiscount addCommerceDiscount(
      String externalReferenceCode, long userId, String title,
      String target, boolean useCouponCode, String couponCode,
      boolean usePercentage, BigDecimal maximumDiscountAmount,
      String level, BigDecimal level1, BigDecimal level2,
      BigDecimal level3, BigDecimal level4, String limitationType,
      int limitationTimes, boolean rulesConjunction, boolean active,
      int displayDateMonth, int displayDateDay, int displayDateYear,
      int displayDateHour, int displayDateMinute, int expirationDateMonth,
      int expirationDateDay, int expirationDateYear,
      int expirationDateHour, int expirationDateMinute,
      boolean neverExpire, ServiceContext serviceContext)
      throws PortalException;

      Delete/Get/Fetch -> Audit foreign keys fields first (e.g. companyId, externalReferenceCode, ...)

      e.g. public WikiPage fetchLatestPageByExternalReferenceCode(
      long groupId, String externalReferenceCode);

      Update -> Mixed, sometimes ERC first and sometimes PK first

       

      MY IDEA:

      ERC always after PK and Audit foreign keys fields (following service.xml order) -> This way we don't need to change how BS is generating finders

      Add -> Audit foreign keys fields first (e.g. userId, externalReferenceCode, ...)

      Get -> Audit foreign keys fields first (e.g. companyId, externalReferenceCode, ...)

      Delete -> Audit foreign keys fields first (e.g. companyId, externalReferenceCode)

      Update -> Audit foreign keys fields and PK first (e.g. userId, externalReferenceCode, ... or entityId, userId, externalReferenceCode, ...)

       

      OTHERWISE

       

      Always before PK and Audit fields (following service.xml order) -> This way we need to change how BS is generating finders in order to have ERC_C (externalReferenceCode, companyId) or ERC_G (externalReferenceCode, groupId)

      Add -> ERC first (e.g. externalReferenceCode, userId, ...)

      Get -> ERC first (e.g. externalReferenceCode, companyId, ...)

      Delete -> ERC first (e.g. externalReferenceCode, companyId)

      Update -> ERC first (e.g. externalReferenceCode, userId, ... or externalReferenceCode, entityId, userId, ...), no matter what we are doing with it, either we need to fetch or update it

       

      This way is still confusing to me on the update and we'll need extra work to change BS and regen all the services introducing breaking changes, so I think it's not worth the effort.

      Of course, I'm open to other solutions.

      Thanks,

      Alessio

      Attachments

        Activity

          People

            alan.huang Alan Huang
            alessio.rendina Alessio Rendina
            Kiyoshi Lee Kiyoshi Lee
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:

              Packages

                Version Package