| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 37481 |
36 d 1 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/ |
imei activation: one 2-day billing floor for every brand, and drop two dead methods
The pending pool is a UNION of two channels, not an intersection: an imei qualifies
if WE billed it to the partner (selectImeiActivationByBrand) or the PARTNER billed it
on to the end customer (selectImeiActivationByBrandTertiary). The two are disjoint by
construction -- the secondary query excludes anything carrying a FofoLineItem -- so a
unit moves from one to the other as it sells through and is never asked about twice.
Said so on the interface, since the pairing was only documented at the call sites.
billedBefore moves from now-1d to now-2d, so both channels ask only about stock billed
MORE THAN 2 DAYS ago. Anything sold in the last 48 hours has essentially never been
activated yet, so the lookup is spent for nothing; it is not lost, the same imei comes
back into the pool as soon as it crosses the floor, and again every day after that
until it activates. Kept in the repository rather than per caller so vivo, oppo, realme,
motorola and the new carlcare pass inherit one rule instead of drifting apart.
Costs almost nothing today -- secondary pool, old floor vs new:
itel 1550 -> 1550 realme 849 -> 849 oppo 2021 -> 2019
vivo 5018 -> 5016 motorola 1168 -> 1153 tecno 502 -> 495
26 rows across six brands, each deferred by one day.
Removed as dead:
selectImeiActivationPendingByRealme -- a verbatim duplicate of
selectImeiActivationPendingByBrand down to the named query and the parameters. Nothing
called it; StandAlone already used the brand-generic method for realme and said so in
a comment, which is now updated.
selectImeiSoldNotActivatedByBrand -- interface, impl and named query. No callers
anywhere in web, fofo, cron or dao. |
|
| 37471 |
36 d 3 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/ |
IMEI activation pools: skip stock billed today or yesterday
Both pool named queries now exclude serials whose sale is inside the last 48
hours -- o.billingTimestamp for the secondary path, fo.createTimestamp for the
tertiary one. A handset sold in the last two days has essentially never been
activated yet, so the lookup is spent for nothing: measured on prod, the
sold-within-180-days cohort returns an activation date on 2.4% (vivo) to 8.4%
(oppo) of lookups, against 43-97% for stock sold over a year ago.
billedBefore is set in ActivatedImeiRepositoryImpl rather than passed by the
caller, so no method signature changes and every brand inherits it -- vivo,
oppo, realme and motorola all draw from these two queries and nothing outside
profitmandi-cron uses them.
This is correctness rather than capacity: it trims 30 imeis from the oppo pool
and 9 from realme. |
|
| 37408 |
41 d 7 h |
amit |
/trunk/ |
Vivo IMEI activation: stop spending captchas on line items with no IMEI
76% of production captcha rejections were line items whose serial number is
null. Vivo answers those with {"msg":"参数为空"} -- "parameter is empty" --
and status 0, which this code recorded as a captcha failure. So a correctly
solved captcha looked wrong, no activated_imei row was written, the line item
stayed pending, and it came back every 5 minutes indefinitely. Those rows were
permanently consuming roughly 43% of the run quota, which is why every tick ran
full at 20/20 and the backlog never drained.
It also made the model look far worse than it is: measured accept rate 44%,
while the same solver scores 85-93% when the IMEI is present. True captcha
accuracy is around 77%.
Fixed at source: both named queries now exclude null and blank serial numbers,
so such line items never enter the pool (this also covers the Realme caller).
The loop additionally skips them before fetching a captcha, so no captcha,
solver call or Vivo request is spent discovering it.
Found via the diagnostics added in r37407 -- the previous log line recorded
five words and discarded the response that named the cause. |
|
| 36972 |
97 d 7 h |
ranu |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/ |
changeList |
|
| 36768 |
125 d 1 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/ |
Restore ActivatedImei.checked idempotency guard (revert r36579)
r36579 removed the 'ai.checked = false' filter from selectMissedActivationSale
and dropped the checked field, treating it as dead. It was not: the filter
prevented the daily activation-scheme sweep from re-processing the ~163K
already-evaluated historical activations (checked=1). Without it, the sweep
resurrected those old activations as PENDING scheme_in_out rows, and the
oldest ones (whose legacy orders have no fofo_order) made processActivation
throw FFORDR_1000 and roll back the entire batch every run since 2026-05-18,
stalling all special-support credits.
Restores the checked field + accessors and the 'ai.checked = false' filter.
checked column repopulated on fofo.activated_imei from backup; rogue PENDING
rows cleaned up separately. |
|
| 36579 |
142 d 4 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/ |
Remove unused checked flag from ActivatedImei; remove dead ai.checked=false filter from selectMissedActivationSale query |
|
| 36261 |
176 d 1 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/ |
Fix JPQL: replace date() and string literals with typed :billingStartDate parameter, use NOT EXISTS instead of NOT IN |
|
| 36259 |
176 d 3 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/ |
Fix: re-apply tertiary query, add NOT NULL guard in NOT IN subquery, @Transactional(readOnly) on repo reads, fix persist ordering in saveActivation |
|
| 36255 |
177 d 6 h |
vikas |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/fofo/ |
ActivatedImei revert |
|
| 36252 |
177 d 9 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/ |
Add tertiary IMEI activation query, shared saveActivation method, fix date() query performance |
|
| 35595 |
251 d 22 h |
amit |
/trunk/profitmandi-dao/ |
Migrate from C3P0 to HikariCP connection pooling
- Replace C3P0 properties with HikariCP settings in all properties files
- Delete unused persistence.xml (was not referenced by any code)
- New settings: maximumPoolSize=20, minimumIdle=2, idleTimeout=30s, maxLifetime=30min |
|
| 35536 |
271 d 3 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
Optimize fetchParnterStats() - fix N+1 query issues
Performance improvements:
- Use batch method getAuthUserAndEsclationByPartnerIds() instead of N+1 loop
- Add new batch method getInvestmentsForFofoStores() to replace N+1 getInvestment() calls
- Add batch query selectActivatedGrnPendingAmountByFofoIds in ActivatedImeiRepository
Before: ~900 queries for 100 stores
After: ~7 queries for 100 stores |
|
| 35466 |
289 d 6 h |
amit |
/trunk/ |
Optimize getActivatedImeiUpdationDate endpoint
- Add 30-day date filter to reduce table scan
- Replace LineItemImeiView with direct LineItemImei table
- Merge results with master brands/warehouses to show all combinations
- Display '-' for missing timestamps instead of hiding rows |
|
| 35464 |
289 d 15 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/ |
Optimize /getActivatedModelByBrand and related activation queries
- Add date range filtering in WHERE clause to use activation_timestamp index
- Replace concat(year,month) with direct date comparisons for better performance
- Optimize getAuthFofoIds to avoid unnecessary DB call when user found in cache
- Use anyMatch() instead of filter().count() for short-circuit evaluation |
|
| 35458 |
289 d 23 h |
amit |
/trunk/ |
Revert @Transactional(readOnly=true) - keep @Transactional only at Controller level
Changes:
- profitmandi-web: Controllers use @Transactional(rollbackFor = Throwable.class) at class level, removed method-level @Transactional(readOnly = true)
- profitmandi-fofo: Controllers use @Transactional(rollbackFor = Throwable.class) at class level, removed method-level @Transactional
- profitmandi-dao: Removed @Transactional from services/repositories
Exceptions (called from interceptors, need own transaction):
- RoleManager: @Transactional(readOnly = true) - called from interceptor for auth
- PartnerTypeChangeServiceImpl.getBestPartner(): @Transactional - called from JWTUtil via interceptor
Fixed javax.transaction.Transactional to org.springframework.transaction.annotation.Transactional
Fixed rollbackOn to rollbackFor for Spring compatibility |
|
| 34641 |
490 d 5 h |
ranu |
/trunk/ |
bi report completed first commit |
|
| 33952 |
685 d 3 h |
aman.kumar |
/trunk/ |
activated imei |
|
| 31860 |
1256 d 5 h |
tejbeer |
/trunk/ |
change |
|
| 31170 |
1418 d 2 h |
amit.gupta |
/trunk/ |
Fixed Duplicate imeis while rolling out additional schemes and Added Region wise schemes |
|
| 30904 |
1499 d 9 h |
amit.gupta |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/fofo/ |
Fixed commit |
|