Conversation
| ) | ||
| } | ||
|
|
||
| def fromCreatePatchPayload(a: OrderShippingAddress, p: CreateAddressPayload) = { |
There was a problem hiding this comment.
@Anna-ZZZ might not like the identifiers. I’m cool with them, but let’s wait before merge, maybe?
There was a problem hiding this comment.
Um, you're right, will fix them.
|
|
||
| storefrontCartsApi.shippingAddress.create(addressPayload).as[TheResponse[CartResponse]] | ||
|
|
||
| customersApi(auth.customerId).addresses.get |
There was a problem hiding this comment.
@Anna-ZZZ, I think that was my question befooore, hmm. Maybe in withNewCustomerAuth block one shouldn’t have access to admin API like customersApi, and it should be explicitly wrapped in withDefaultAdminAuth or similar. Which would mean that we’d need to remove with DefaultAdminAuth trait and wrap alsmost all existing tests. Hmmm. Well. ¯\_(ツ)_/¯
There was a problem hiding this comment.
Request is sent with customer auth anyways because of implicits
|
Going to update this a bit |
| for { | ||
| shippingAddresses ← q | ||
| adr ← Addresses | ||
| if adr.accountId === accountId && adr.address1 === shippingAddresses.address1 && adr.name === shippingAddresses.name |
There was a problem hiding this comment.
We don't have fk to Address so I need this little hack to locate related Address for now to bootstrap ApplePay thing (gonna be used only in AP, so we're safe here). Otherwise risking to blow up this scope. I have a better plan how we can address this relation, will provide info on that later.
| implicit class EnrichedDBIOpt[R](val dbio: DBIO[Option[R]]) extends AnyVal { | ||
|
|
||
| def findOrCreate(r: DbResultT[R])(implicit ec: EC): DbResultT[R] = { | ||
| def findOrCreate(createAction: ⇒ DbResultT[R])(implicit ec: EC): DbResultT[R] = { |
There was a problem hiding this comment.
Again, evaluated on spot. Gonna investigate if we have more of these. Wonder why ITs are not catching this 🤔
There was a problem hiding this comment.
Why should ITs catch this? DbResultT by itself does not execute any action, so there wasn't any creation involved.
We spare though now allocation of DbResultT when something is actually found, which I guess is more costly than plain function allocation (call-by-name overhead).
There was a problem hiding this comment.
Huh, you right. I wasn't thinking through this carefully. I was getting unique constraint violation at the time I got to this point. And quickly assumed that was the reason.
annappropriate
left a comment
annappropriate
left a comment
There was a problem hiding this comment.
Is frontend ready for this? Or separate changeset?
| def * = | ||
| (id, cordRef, regionId, name, address1, address2, city, zip, phoneNumber, createdAt, updatedAt) <> ((OrderShippingAddress.apply _).tupled, OrderShippingAddress.unapply) | ||
|
|
||
| // FIXME this fk is not reflected in db schema @aafa |
|
|
||
| storefrontCartsApi.shippingAddress.create(addressPayload).as[TheResponse[CartResponse]] | ||
|
|
||
| customersApi(auth.customerId).addresses.get |
There was a problem hiding this comment.
Request is sent with customer auth anyways because of implicits
# Conflicts: # phoenix-scala/core/app/core/db/package.scala # phoenix-scala/phoenix/app/phoenix/models/cord/OrderShippingAddress.scala # phoenix-scala/phoenix/app/phoenix/routes/admin/CartRoutes.scala # phoenix-scala/phoenix/app/phoenix/services/carts/CartShippingAddressUpdater.scala # phoenix-scala/phoenix/test/integration/AddressesIntegrationTest.scala # phoenix-scala/phoenix/test/integration/CartValidatorIntegrationTest.scala # phoenix-scala/phoenix/test/integration/ShippingMethodsIntegrationTest.scala # phoenix-scala/phoenix/test/integration/services/CheckoutTest.scala # phoenix-scala/phoenix/test/integration/services/ShippingManagerTest.scala # phoenix-scala/phoenix/test/integration/testutils/apis/PhoenixStorefrontApi.scala
4 participants
This PR
The reason for it is to have PUT as an idempotent version of POST with createOrUpdate logic to simplify things for the frontend.