د دې کیسه چې څنګه په ریالم کې د کاسکیډ حذف کول په اوږده لانچ کې وګټل

ټول کاروونکي په ګرځنده غوښتنلیکونو کې ګړندي لانچ او ځواب ورکوونکی UI په وړیا توګه اخلي. که چیرې اپلیکیشن پیل کولو کې ډیر وخت ونیسي ، نو کارونکي د خپګان او غوسه کیدو احساس پیل کوي. تاسو کولی شئ په اسانۍ سره د پیرودونکي تجربه خرابه کړئ یا په بشپړ ډول کاروونکي له لاسه ورکړئ حتی مخکې لدې چې هغه د غوښتنلیک کارول پیل کړي.

موږ یوځل وموندله چې د ډوډو پیزا ایپ په اوسط ډول پیل کولو لپاره 3 ثانیې وخت نیسي ، او د ځینې "خوشحالو" لپاره دا 15-20 ثانیې وخت نیسي.

د کټ لاندې د خوښې پای سره یوه کیسه ده: د رییلم ډیټابیس وده په اړه ، د حافظې لیک ، څنګه موږ ځړول شوي توکي راټول کړل ، او بیا یې ځان سره یوځای کړ او هرڅه یې تنظیم کړل.

د مقالې لیکوال: ماکسیم کاچینکین - په ډوډو پیزا کې د Android پراختیا کونکی.

د لومړي فعالیت آن ریزیوم () ته د اپلیکیشن آئیکون کلیک کولو څخه درې ثانیې انفینیت دی. او د ځینو کاروونکو لپاره، د پیل وخت 15-20 ثانیو ته ورسید. دا څنګه ممکنه ده؟

د هغو کسانو لپاره چې د لوستلو لپاره وخت نلري خورا لنډ لنډیز
زموږ د ریال ډیټابیس بې پایه وده وکړه. ځینې ​​ځړول شوي توکي نه دي حذف شوي ، مګر په دوامداره توګه راټول شوي. د غوښتنلیک د پیل وخت په تدریجي ډول زیات شو. بیا موږ دا تنظیم کړه، او د پیل کولو وخت هدف ته ورسید - دا د 1 ثانیو څخه کم شو او نور نه زیاتیږي. مقاله د وضعیت تحلیل او دوه حلونه لري - یو چټک او یو نورمال.

د ستونزې لټون او تحلیل

نن ورځ، هر ګرځنده غوښتنلیک باید په چټکۍ سره پیل شي او ځواب ویونکي وي. مګر دا یوازې د ګرځنده ایپ په اړه ندي. د خدمت او شرکت سره د متقابل عمل تجربه یو پیچلی شی دی. د مثال په توګه، زموږ په قضیه کې، د سپارلو سرعت د پیزا خدمت لپاره یو له مهمو شاخصونو څخه دی. که تحویلي ګړندي وي ، پیزا به ګرم وي ، او پیرودونکي چې غواړي اوس وخوري نو ډیر انتظار ته اړتیا نلري. د غوښتنلیک لپاره، په بدل کې، دا مهمه ده چې د چټک خدمت احساس رامنځته کړئ، ځکه چې که غوښتنلیک یوازې 20 ثانیې پیل کړي، نو تاسو به د پیزا لپاره څومره وخت انتظار وکړئ؟

په لومړي سر کې، موږ پخپله د دې حقیقت سره مخ شوي یو چې ځینې وختونه د غوښتنلیک په پیل کې څو ثانیې وخت نیسي، او بیا موږ د نورو همکارانو څخه شکایتونه اوریدل پیل کړل چې دا څومره وخت نیسي. مګر موږ نشو کولی دا حالت په دوامداره توګه تکرار کړو.

څومره وخت دی؟ په وینا د د ګوګل اسناد، که چیرې د غوښتنلیک ساړه پیل له 5 ثانیو څخه لږ وخت ونیسي ، نو دا "لکه نورمال" ګڼل کیږي. د ډوډو پیزا Android ایپ پیل شو (د فایربیس میټریکونو سره سم _app_startپه سړه پیل په اوسط ډول په 3 ثانیو کې - "لوی نه، نه ډارونکی،" لکه څنګه چې دوی وايي.

مګر بیا شکایتونه څرګندیدل پیل شول چې غوښتنلیک په پیل کولو کې خورا ، خورا ، خورا اوږد وخت نیولی! د پیل کولو لپاره، موږ پریکړه وکړه چې اندازه کړو چې "ډیر، ډیر، ډیر اوږد" څه شی دی. او موږ د دې لپاره د Firebase ټریس کاروو د اپلیکیشن پیل ټریس.

دا معیاري ټریس د هغه شیبې ترمینځ وخت اندازه کوي چې کارونکي غوښتنلیک خلاصوي او هغه شیبه چې د لومړي فعالیت onResume() اجرا کیږي. په فایربیس کنسول کې دا میټریک د _app_start په نوم یادیږي. دا معلومه شوه چې:

• د 95 سلنې څخه پورته کاروونکو لپاره د پیل وختونه نږدې 20 ثانیې دي (ځینې حتی اوږد)، سره له دې چې د منځني سړه پیل وخت له 5 ثانیو څخه کم دی.
• د پیل وخت ثابت ارزښت نه دی، مګر د وخت په تیریدو سره وده کوي. مګر ځینې وختونه څاڅکي شتون لري. موږ دا نمونه وموندله کله چې موږ د تحلیل کچه 90 ورځو ته لوړه کړه.

په ذهن کې دوه فکرونه راغلل:

1. یو څه لیکیږي.
2. دا "یو څه" د خوشې کیدو وروسته بیا تنظیم شوی او بیا لیک کیږي.

"شاید د ډیټابیس سره یو څه ،" موږ فکر کاوه ، او موږ سم وو. لومړی، موږ ډیټابیس د کیچ په توګه کاروو؛ د مهاجرت په جریان کې موږ دا پاکوو. دوهم، ډیټابیس پورته کیږي کله چې غوښتنلیک پیل شي. هر څه یوځای سره سمون لري.

د Realm ډیټابیس سره څه شی دی

موږ دا وګورو چې څنګه د ډیټابیس مینځپانګې د غوښتنلیک په ژوند کې بدلون راولي ، له لومړي نصب څخه او نور د فعال کارونې پرمهال. تاسو کولی شئ د Realm ډیټابیس مینځپانګې له لارې وګورئ سټوټو یا په ډیر تفصیل سره او په روښانه ډول د فایل له لارې خلاصولو سره Realm Studio. د ADB له لارې د ډیټابیس مینځپانګې لیدو لپاره ، د ریالم ډیټابیس فایل کاپي کړئ:

adb exec-out run-as ${PACKAGE_NAME} cat files/${DB_NAME}

په بیلابیلو وختونو کې د ډیټابیس مینځپانګې ته په کتلو سره ، موږ وموندله چې د یو ځانګړي ډول شیانو شمیر په دوامداره توګه وده کوي.

عکس د دوه فایلونو لپاره د رییلم سټوډیو یوه ټوټه ښیې: په ښي خوا کې - د نصب کولو وروسته یو څه وخت د غوښتنلیک اساس ، ښي خوا - د فعال کارونې وروسته. دا لیدل کیدی شي چې د شیانو شمیر ImageEntity и MoneyType د پام وړ وده کړې (د سکرین شاټ د هر ډول شیانو شمیر ښیې).

د ډیټابیس وده او د پیل وخت ترمنځ اړیکه

غیر کنټرول شوي ډیټابیس وده خورا خرابه ده. مګر دا څنګه د غوښتنلیک پیل کولو وخت اغیزه کوي؟ د فعالیت مدیر له لارې دا اندازه کول خورا اسانه دي. د Android 4.4 راهیسې، logcat د ښودل شوي تار او وخت سره لاګ ښکاره کوي. دا وخت د وقفې سره مساوي دی له هغه شیبې څخه چې غوښتنلیک پیل شوی د فعالیت رینډرینګ پای پورې. پدې موده کې لاندې پیښې واقع کیږي:

• پروسه پیل کړئ.
• د شیانو پیل کول.
• د فعالیتونو رامینځته کول او پیل کول.
• د ترتیب جوړول.
• د غوښتنلیک وړاندې کول.

موږ ته مناسب. که تاسو ADB د -S او -W بیرغونو سره پرمخ وړئ، تاسو کولی شئ د پیل وخت سره پراخ شوي محصول ترلاسه کړئ:

adb shell am start -S -W ru.dodopizza.app/.MainActivity -c android.intent.category.LAUNCHER -a android.intent.action.MAIN

که تاسو یې له هغه ځایه واخلئ grep -i WaitTime وخت، تاسو کولی شئ د دې میټریک راټولول اتومات کړئ او پایلې یې په لید کې وګورئ. لاندې ګراف د غوښتنلیک د پیل کولو وخت پورې تړاو د غوښتنلیک د سړې پیل په شمیر ښیي.

په ورته وخت کې، د ډیټابیس د اندازې او ودې ترمنځ د اړیکو ورته طبیعت شتون درلود، کوم چې له 4 MB څخه 15 MB ته وده ورکړه. په مجموع کې، دا معلومه شوه چې د وخت په تیریدو سره (د ساړه پیل وده سره)، د غوښتنلیک پیل کولو وخت او د ډیټابیس اندازه دواړه زیات شوي. موږ زموږ په لاسونو کې فرضیه لرو. اوس ټول هغه څه پاتې وو چې د انحصار تصدیق کول وو. له همدې امله ، موږ پریکړه وکړه چې "لیک" لرې کړو او وګورو چې ایا دا به لانچ ګړندی کړي.

د نه ختمیدونکي ډیټابیس ودې لاملونه

د "لیکونو" لرې کولو دمخه، دا د پوهیدو وړ ده چې ولې دوی په لومړي ځای کې ښکاره شوي. د دې کولو لپاره، راځئ چې په یاد ولرو چې سیمه څه ده.

Realm یو غیر اړونده ډیټابیس دی. دا تاسو ته اجازه درکوي د شیانو ترمینځ اړیکې په ورته ډول تشریح کړئ چې په Android کې څومره ORM اړوند ډیټابیسونه بیان شوي. په ورته وخت کې ، رییلم توکي په مستقیم ډول په حافظه کې د لږترلږه بدلونونو او نقشو سره ذخیره کوي. دا تاسو ته اجازه درکوي په چټکۍ سره د ډیسک څخه ډاټا ولولئ، کوم چې د رییلم ځواک دی او ولې دا مینه لري.

(د دې مقالې د موخو لپاره، دا توضیحات به زموږ لپاره کافي وي. تاسو کولی شئ په یخ کې د ریالم په اړه نور ولولئ اسناد یا په دوی کې اکاډمي).

ډیری پراختیا کونکي د اړونده ډیټابیسونو سره ډیر کار کولو عادت لري (د مثال په توګه ، د هود لاندې SQL سره ORM ډیټابیسونه). او شیان لکه د کاسکیډینګ ډیټا حذف کول اکثرا د ورکړل شوي په څیر ښکاري. مګر په سیمه کې نه.

په هرصورت، د cascade حذف کولو ځانګړتیا د اوږدې مودې لپاره غوښتنه شوې. دا بیاکتنه и بلد دې سره تړلې، په فعاله توګه بحث وشو. داسې احساس شتون درلود چې دا به ډیر ژر ترسره شي. مګر بیا هرڅه د قوي او ضعیف لینکونو معرفي کولو کې ژباړل شوي، چې دا به پخپله دا ستونزه حل کړي. په دې دنده کې خورا فعال او فعال و د ایستلو غوښتنه، چې د داخلي ستونزو له امله د اوس لپاره ځنډول شوی.

د ډیټا لیک پرته له مینځه وړل

که تاسو په غیر موجود کاسکیډینګ حذف باندې تکیه کوئ نو دقیقا څنګه ډیټا لیک کیږي؟ که تاسو د ریلم توکي ځړول شوي وي ، نو دوی باید حذف شي.
راځئ چې یو (تقریبا) ریښتینی مثال وګورو. موږ یو اعتراض لرو CartItemEntity:

@RealmClass
class CartItemEntity(
 @PrimaryKey
 override var id: String? = null,
 ...
 var name: String = "",
 var description: String = "",
 var image: ImageEntity? = null,
 var category: String = MENU_CATEGORY_UNKNOWN_ID,
 var customizationEntity: CustomizationEntity? = null,
 var cartComboProducts: RealmList<CartProductEntity> = RealmList(),
 ...
) : RealmObject()

په کارټ کې محصول مختلف ساحې لري، په شمول د انځور ImageEntity، دودیز اجزا CustomizationEntity. همچنان ، په کارټ کې محصول کولی شي د خپل محصولاتو سیټ سره کومبو وي RealmList (CartProductEntity). ټول لیست شوي ساحې د ریلم توکي دي. که موږ د ورته id سره یو نوی څیز (copyToRealm() / copyToRealmOrUpdate()) داخل کړو نو دا اعتراض به په بشپړ ډول له سره لیکل کیږي. مګر ټول داخلي شیان (انځور، customizationEntity او cartComboProducts) به د مور او پلار سره اړیکه له لاسه ورکړي او په ډیټابیس کې پاتې شي.

څرنګه چې د دوی سره اړیکه له لاسه ورکړې، موږ نور دوی نه لوستلو یا یې حذف کوو (مګر که موږ دوی ته په واضح ډول لاسرسی ونیسو یا ټول "میز" پاک کړو). موږ دې ته "یاد لیکونه" وایو.

کله چې موږ د ریلم سره کار کوو، موږ باید په ښکاره ډول د ټولو عناصرو له لارې لاړ شو او د داسې عملیاتو دمخه هرڅه په واضح ډول حذف کړو. دا د مثال په توګه ترسره کیدی شي:

val entity = realm.where(CartItemEntity::class.java).equalTo("id", id).findFirst()
if (first != null) {
 deleteFromRealm(first.image)
 deleteFromRealm(first.customizationEntity)
 for(cartProductEntity in first.cartComboProducts) {
   deleteFromRealm(cartProductEntity)
 }
 first.deleteFromRealm()
}
// и потом уже сохраняем

که تاسو دا وکړئ، نو هر څه به کار وکړي لکه څنګه چې باید وي. پدې مثال کې ، موږ فرض کوو چې د عکس ، customizationEntity ، او cartComboProducts دننه هیڅ نور نیست شوي ریلم توکي شتون نلري ، نو دلته نور نست شوي لوپونه او حذفونه شتون نلري.

"چټک" حل

لومړی شی چې موږ یې پریکړه وکړه د ګړندۍ وده کونکي توکي پاک کړئ او پایلې یې وګورئ ترڅو وګورئ چې ایا دا به زموږ اصلي ستونزه حل کړي. لومړی، ترټولو ساده او خورا هوښیار حل رامینځته شوی، یعنې: هر شی باید د خپلو ماشومانو د لرې کولو مسولیت ولري. د دې کولو لپاره ، موږ یو انٹرفیس معرفي کړ چې د دې د ځړول شوي ریلم شیانو لیست یې راستون کړ:

interface NestedEntityAware {
 fun getNestedEntities(): Collection<RealmObject?>
}

او موږ دا زموږ په سیمه ایزو شیانو کې پلي کړل:

@RealmClass
class DataPizzeriaEntity(
 @PrimaryKey
 var id: String? = null,
 var name: String? = null,
 var coordinates: CoordinatesEntity? = null,
 var deliverySchedule: ScheduleEntity? = null,
 var restaurantSchedule: ScheduleEntity? = null,
 ...
) : RealmObject(), NestedEntityAware {

 override fun getNestedEntities(): Collection<RealmObject?> {
   return listOf(
       coordinates,
       deliverySchedule,
       restaurantSchedule
   )
 }
}

В getNestedEntities موږ ټول ماشومان د فلیټ لیست په توګه بیرته راګرځوو. او د ماشوم هر څیز کولی شي د NestedEntityAware انٹرفیس هم پلي کړي، دا په ګوته کوي چې دا د حذف کولو لپاره داخلي رییلم توکي لري، د بیلګې په توګه ScheduleEntity:

@RealmClass
class ScheduleEntity(
 var monday: DayOfWeekEntity? = null,
 var tuesday: DayOfWeekEntity? = null,
 var wednesday: DayOfWeekEntity? = null,
 var thursday: DayOfWeekEntity? = null,
 var friday: DayOfWeekEntity? = null,
 var saturday: DayOfWeekEntity? = null,
 var sunday: DayOfWeekEntity? = null
) : RealmObject(), NestedEntityAware {

 override fun getNestedEntities(): Collection<RealmObject?> {
   return listOf(
       monday, tuesday, wednesday, thursday, friday, saturday, sunday
   )
 }
}

او داسې نور، د شیانو ځړول تکرار کیدی شي.

بیا موږ یو میتود لیکو چې په تکراري ډول ټول ځړول شوي توکي حذف کوي. میتود (د توسیع په توګه جوړ شوی) deleteAllNestedEntities ټول لوړ پوړ توکي او میتود ترلاسه کوي deleteNestedRecursively په تکراري ډول د NestedEntityAware انٹرفیس په کارولو سره ټول ځړول شوي توکي لرې کوي:

fun <T> Realm.deleteAllNestedEntities(entities: Collection<T>,
 entityClass: Class<out RealmObject>,
 idMapper: (T) -> String,
 idFieldName : String = "id"
 ) {

 val existedObjects = where(entityClass)
     .`in`(idFieldName, entities.map(idMapper).toTypedArray())
     .findAll()

 deleteNestedRecursively(existedObjects)
}

private fun Realm.deleteNestedRecursively(entities: Collection<RealmObject?>) {
 for(entity in entities) {
   entity?.let { realmObject ->
     if (realmObject is NestedEntityAware) {
       deleteNestedRecursively((realmObject as NestedEntityAware).getNestedEntities())
     }
     realmObject.deleteFromRealm()
   }
 }
}

موږ دا د ګړندۍ وده کونکي شیانو سره ترسره کړل او وګوره چې څه پیښ شوي.

د پایلې په توګه، هغه توکي چې موږ د دې حل سره پوښلي د ودې مخه نیسي. او د اډې عمومي وده ورو شوه، مګر ودرېده.

د "عادي" حل

که څه هم اډې په ورو ورو وده پیل کړه، بیا هم وده وکړه. نو موږ نور په لټه کې شو. زموږ پروژه په ریالم کې د ډیټا کیشینګ خورا فعاله ګټه پورته کوي. له همدې امله، د هر څیز لپاره د ټولو نیست شوي شیانو لیکل د کار وړ دي، او د غلطیو خطر ډیریږي، ځکه چې تاسو کولی شئ د کوډ بدلولو په وخت کې د شیانو مشخص کول هیر کړئ.

ما غوښتل ډاډ ترلاسه کړم چې ما انٹرفیس نه دی کارولی، مګر دا چې هرڅه پخپله کار کوي.

کله چې موږ غواړو یو څه پخپله کار وکړو، موږ باید انعکاس وکاروو. د دې کولو لپاره، موږ کولی شو د هر ټولګي ساحې ته لاړ شو او وګورو چې ایا دا د ریلم څیز دی یا د شیانو لیست:

RealmModel::class.java.isAssignableFrom(field.type)

RealmList::class.java.isAssignableFrom(field.type)

که چیرې ساحه د RealmModel یا RealmList وي، نو د دې ساحې څیز د نیست شوي شیانو لیست کې اضافه کړئ. هرڅه په بشپړ ډول ورته دي لکه څنګه چې موږ پورته کړي، یوازې دلته به دا پخپله ترسره شي. د کاسکیډ حذف کولو میتود پخپله خورا ساده دی او داسې ښکاري:

fun <T : Any> Realm.cascadeDelete(entities: Collection<T?>) {
 if(entities.isEmpty()) {
   return
 }

 entities.filterNotNull().let { notNullEntities ->
   notNullEntities
       .filterRealmObject()
       .flatMap { realmObject -> getNestedRealmObjects(realmObject) }
       .also { realmObjects -> cascadeDelete(realmObjects) }

   notNullEntities
       .forEach { entity ->
         if((entity is RealmObject) && entity.isValid) {
           entity.deleteFromRealm()
         }
       }
 }
}

تمدید filterRealmObject فلټر کوي او یوازې د ریلم توکي تیریږي. طریقه getNestedRealmObjects د انعکاس له لارې، دا ټول نیست شوي ریلم توکي پیدا کوي او په یو خطي لیست کې یې اچوي. بیا موږ ورته کار په تکرار سره کوو. کله چې حذف کول، تاسو اړتیا لرئ د اعتبار لپاره اعتراض وګورئ isValid, ځکه چې کیدای شي دا وي چې مختلف اصلي شیان کیدای شي ورته ورته ځالې ولري. دا غوره ده چې له دې څخه مخنیوی وشي او په ساده ډول د نوي شیانو رامینځته کولو پرمهال د ID اتوماتیک نسل وکاروئ.

د getNestedRealmObjects میتود بشپړ پلي کول

private fun getNestedRealmObjects(realmObject: RealmObject) : List<RealmObject> {
 val nestedObjects = mutableListOf<RealmObject>()
 val fields = realmObject.javaClass.superclass.declaredFields

// Проверяем каждое поле, не является ли оно RealmModel или списком RealmList
 fields.forEach { field ->
   when {
     RealmModel::class.java.isAssignableFrom(field.type) -> {
       try {
         val child = getChildObjectByField(realmObject, field)
         child?.let {
           if (isInstanceOfRealmObject(it)) {
             nestedObjects.add(child as RealmObject)
           }
         }
       } catch (e: Exception) { ... }
     }

     RealmList::class.java.isAssignableFrom(field.type) -> {
       try {
         val childList = getChildObjectByField(realmObject, field)
         childList?.let { list ->
           (list as RealmList<*>).forEach {
             if (isInstanceOfRealmObject(it)) {
               nestedObjects.add(it as RealmObject)
             }
           }
         }
       } catch (e: Exception) { ... }
     }
   }
 }

 return nestedObjects
}

private fun getChildObjectByField(realmObject: RealmObject, field: Field): Any? {
 val methodName = "get${field.name.capitalize()}"
 val method = realmObject.javaClass.getMethod(methodName)
 return method.invoke(realmObject)
}

د پایلې په توګه، زموږ د پیرودونکي کوډ کې موږ د هر ډیټا ترمیم عملیاتو لپاره "کاسکیډینګ حذف" کاروو. د مثال په توګه، د ننوتلو عملیاتو لپاره دا داسې ښکاري:

override fun <T : Entity> insert(
 entityInformation: EntityInformation,
 entities: Collection<T>): Collection<T> = entities.apply {
 realmInstance.cascadeDelete(getManagedEntities(entityInformation, this))
 realmInstance.copyFromRealm(
     realmInstance
         .copyToRealmOrUpdate(this.map { entity -> entity as RealmModel }
 ))
}

لومړی طریقه getManagedEntities ټول اضافه شوي توکي ترلاسه کوي، او بیا طریقه cascadeDelete د نوي لیکلو دمخه ټول راټول شوي توکي په تکراري ډول حذف کوي. موږ د غوښتنلیک په اوږدو کې د دې طریقې کار اخلو. په ریالم کې د حافظې لیکونه په بشپړ ډول ورک شوي. د غوښتنلیک د سړې پیل په شمیر باندې د پیل کولو وخت انحصار ورته اندازه کولو سره ، موږ پایله ګورو.

شنه کرښه د اپلیکیشن د پیل کولو وخت انحصار ښیې چې د یخ پیل په شمیر کې د نیست شوي شیانو د اتوماتیک کاسکیډ حذف کولو پرمهال.

پایلې او پایلې

د تل وده کونکي رییلم ډیټابیس د دې لامل شوی چې غوښتنلیک خورا ورو پیل کړي. موږ د خپل ځړول شوي شیانو د خپل "کاسکیډینګ حذف" سره یو تازه خپور کړ. او اوس موږ څارنه او ارزونه کوو چې څنګه زموږ پریکړه د _app_start میټریک له لارې د غوښتنلیک پیل کولو وخت اغیزه کړې.

د تحلیل لپاره، موږ د 90 ورځو وخت نیسو او وګورو: د غوښتنلیک د پیل وخت، دواړه منځنۍ او هغه چې د کاروونکو په 95 فیصده کې راځي، کمیدل پیل شوي او نور نه لوړیږي.

که تاسو د اوه ورځو چارټ وګورئ، د _app_start میټریک په بشپړه توګه کافي ښکاري او د 1 ثانیو څخه کم دی.

دا د اضافه کولو ارزښت هم لري چې د ډیفالټ په واسطه ، فایربیس خبرتیاوې لیږي که چیرې د _app_start منځنی ارزښت له 5 ثانیو څخه ډیر وي. په هرصورت، لکه څنګه چې موږ لیدلی شو، تاسو باید پدې تکیه ونکړئ، بلکه دننه لاړ شئ او په ښکاره توګه یې وګورئ.

د رییلم ډیټابیس په اړه ځانګړی شی دا دی چې دا یو غیر اړونده ډیټابیس دی. د دې د کارولو اسانتیا سره سره، د ORM حلونو او د اعتراض لینک کولو سره ورته والی، دا د کاسکیډ حذف نه لري.

که دا په پام کې ونه نیول شي، نو ځړول شوي شیان به راټول شي او "لیرې شي." ډیټابیس به په دوامداره توګه وده وکړي ، کوم چې په پایله کې به د غوښتنلیک ورو یا پیل اغیزه وکړي.

ما زموږ تجربه شریکه کړه چې څنګه په ریالم کې د شیانو د کاسکیډ حذف کولو څرنګوالی ترسره کړئ ، کوم چې لاهم د بکس څخه بهر ندی ، مګر د اوږدې مودې راهیسې خبرې شوي. دوی وایي и دوی وایي. زموږ په قضیه کې ، دې د غوښتنلیک پیل کولو وخت خورا ګړندی کړ.

د دې خصوصیت د نږدې ظهور په اړه د بحث سره سره، په ریالم کې د کاسکیډ حذف کولو نشتوالی د ډیزاین لخوا ترسره کیږي. که تاسو یو نوی غوښتنلیک ډیزاین کوئ، نو دا په پام کې ونیسئ. او که تاسو دمخه ریلیم کاروئ ، وګورئ چې ایا تاسو ورته ستونزې لرئ.

سرچینه: www.habr.com