icom/ framework

ອ່ານຂໍ້ມູນໃຫຍ່ເປັນໜ້ານ້ອຍ.

ໃຊ້ indexed ordering key ແລະຂອບເຂດຈຳນວນແຖວ ເພື່ອຫຼີກການອ່ານທັງຕາຕະລາງເຂົ້າ memory.

API ພື້ນຖານ

cursorPaginate ອ່ານສູງສຸດ perPage + 1 ແຖວ ເພື່ອຮູ້ວ່າມີໜ້າຕໍ່ໄປຫຼືບໍ່. perPage ຕ້ອງຢູ່ 1–500. ທຸກ where condition ຂອງ query ເດີມຍັງຄົງຢູ່; cursor input ຖືກ bind ເປັນ SQL parameter.

example
$page = $db->table('products')
    ->where('tenant_id', $authorizedTenant)
    ->cursorPaginate('id', perPage: 50, after: $after,
        columns: ['id', 'name']);

return \Icom\Http\Response::json($page);
// {data: [...], per_page: 50, has_more: true, next_cursor: "p050"}

Key ທີ່ຖືກຕ້ອງ

ໃຊ້ key ທີ່ unique ໃນຂອບເຂດ query, ບໍ່ເປັນ NULL/empty ແລະບໍ່ປ່ຽນຄ່າລະຫວ່າງການແບ່ງໜ້າ. ຕົວຢ່າງ PRIMARY KEY(tenant_id,id) ເໝາະກັບ where tenant_id = ?. ຄ່າ key ຕ້ອງເປັນ integer ຫຼື string ສູງສຸດ 512 bytes. ຖ້າເລືອກ columns ເອງ ຕ້ອງມີ key ນັ້ນນຳ. ຊື່ຫຼື timestamp ທີ່ຊ້ຳກັນບໍ່ເໝາະເປັນ key ດຽວ.

ອ່ານໜ້າຕໍ່ໄປ

example
$query = $db->table('products')->where('tenant_id', $authorizedTenant);
$first = $query->cursorPaginate('id', 20);
if ($first->hasMore) {
    $next = $query->cursorPaginate('id', 20, $first->nextCursor);
}
// For descending order, pass direction: 'DESC' on every request.
// The last page has has_more=false and next_cursor=null.

ສິດເຂົ້າເຖິງ ແລະຂໍ້ຈຳກັດ

Cursor ເປັນຄ່າລຽງລຳດັບ ບໍ່ແມ່ນໂທເຄັນອະນຸຍາດ. ກວດ user/tenant ໃໝ່ທຸກ request ແລະຮັກສາ filter ເດີມ. Pagination ນີ້ບໍ່ມີ total count, ເລກໜ້າ, composite cursor ຫຼື snapshot ຂໍ້ມູນ. ແຖວທີ່ເພີ່ມກ່ອນ cursor ຈະບໍ່ປາກົດຈົນເລີ່ມອ່ານໃໝ່. ບໍ່ໃຊ້ຮ່ວມກັບ orderBy/limit ທີ່ກຳນົດໄວ້ກ່ອນ. ກວດ query plan/index ໃນຖານຂໍ້ມູນຈິງ; ບໍ່ມີການຮັບປະກັນຄວາມໄວໂດຍອັດຕະໂນມັດ.

Developer preview — benchmark claims require reproducible evidence.

Explore the architecture