Регистрация  |  Вход

Приходилось ли вам бороться с данными лимитами?

Привет всем.

Вопрос к вашему практическому опыту.

В новом релизе Salesforce Summer '13 изменился подход к расчету лимитов по асинхронным процессам

Приходилось ли вам бороться с данными лимитами? Хотелось бы услышать реальный практический пример.

Например, у нас на фирме практикуют использование батч (метода start) вместо вызова @future метода.

Привет всем.

Вопрос к вашему практическому опыту.

В новом релизе Salesforce Summer '13 [url=http://salesforce-developer.ru/novyiy-podhod-k-raschetu-limitov-dlya-asinhronnyih-protsessov-daily-asynchronous-limit/]изменился подход к расчету лимитов по асинхронным процессам[/url] 

Приходилось ли вам бороться с данными лимитами? Хотелось бы услышать реальный практический пример.

Например, у нас на фирме практикуют использование батч (метода start) вместо вызова @future метода.

Продолжу тему о лимитах, но о самых простых ее аспектах.

Нашел, что число DML операций за один run не должно превышать 150. Проверил, поставив select внутри цикла - так и есть. Но это не проблема.

Более сложно: почему-то запало в голову, что кол-во выквериных selectом записей не должно превышать 200 (хотя на "Understanding Execution Governors and Limits" пишут о 50,000).

Попробовал: выбрал в Лист 1700 записей (проверил через debug(myList.Size());).

Попробовал insert (другой) List: вставил 500 записей.

Хочу спросить более опытных специалистов:
Где пределы для кол-ва записей выбранных selectом, при том, что я выбираю только ID и пару "коротких" полей, вроде лук-ап поля.

Где пределы кол-ва вставляемых и, что более важно, апдатируемых записей при тех же условиях?

(в обоих случаях идет речь о коде, исполняемом в консоли)

Как узнать общее число записей в объекте?

Спасибо

Продолжу тему о лимитах, но о самых простых ее аспектах.

Нашел, что число DML операций за один run не должно превышать 150. Проверил, поставив select внутри цикла - так и есть. Но это не проблема.

Более сложно: почему-то запало в голову, что кол-во выквериных selectом записей не должно превышать 200 (хотя на "Understanding Execution Governors and Limits" пишут о  50,000).

Попробовал: выбрал в Лист 1700 записей (проверил через debug(myList.Size());). 

Попробовал insert (другой) List: вставил 500 записей.

Хочу спросить более опытных специалистов:
Где пределы для кол-ва записей выбранных selectом, при том, что я выбираю только ID и пару "коротких" полей, вроде лук-ап поля.

Где пределы кол-ва вставляемых и, что более важно, апдатируемых записей при тех же условиях?

(в обоих случаях идет речь о коде, исполняемом в консоли)

Как узнать общее число записей в объекте?

Спасибо

Den Brown

У тебя небольшой бардак в голове по поводу лимитов, извини за прямоту.

Вот эта страница расскажет тебе обо всех актуальных лимитах на Salesforce
Understanding Execution Governors and Limits

Немного поправок по твоему сообщению.

Нашел, что число DML операций за один run не должно превышать 150. Проверил, поставив select внутри цикла - так и есть. Но это не проблема.

Select это не DML операция.
DML = insert, updated, delete; операций = 150
SOQL = select; операций = 100
есть еще SOSL, но это отдельная большая тема.

Более сложно: почему-то запало в голову, что кол-во выквериных selectом записей не должно превышать 200 (хотя на "Understanding Execution Governors and Limits" пишут о 50,000).

SOQL запрос может вернуть максимум 50 000 записей. Откуда ты взял 200 непонятно.

Где пределы для кол-ва записей выбранных selectом, при том, что я выбираю только ID и пару "коротких" полей, вроде лук-ап поля.

Предел 50 000 записей, независимо что ты там выбираешь и сколько данных через связи подтягиваешь.

Где пределы кол-ва вставляемых и, что более важно, апдатируемых записей при тех же условиях?

10,000 записей

Как узнать общее число записей в объекте?

Вот тут все сложно!!!!
Есть такой запрос
Integer count = [SELECT COUNT() FROM Contact]
он вернет тебе количество записей которые который выберет данный запрос.
НО на этот запрос тоже распространяется ограничение в 50 000 записей, т.е. если у тебя в базе больше 50000 записей получишь Exception.
В интернете есть много workaround решений данного вопроса.

Den Brown

У тебя небольшой бардак в голове по поводу лимитов, извини за прямоту.

Вот эта страница расскажет тебе обо всех актуальных лимитах на Salesforce
[url=http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_gov_limits.htm]Understanding Execution Governors and Limits[/url]

Немного поправок по твоему сообщению.

[quote]Нашел, что число DML операций за один run не должно превышать 150. Проверил, поставив select внутри цикла - так и есть. Но это не проблема.[/quote]

Select это не DML операция. 
[b]DML = insert, updated, delete[/b]; операций = 150
[b]SOQL = select[/b]; операций = 100
есть еще [b]SOSL[/b], но это отдельная большая тема.

[quote]Более сложно: почему-то запало в голову, что кол-во выквериных selectом записей не должно превышать 200 (хотя на "Understanding Execution Governors and Limits" пишут о 50,000).[/quote]
SOQL запрос может вернуть максимум 50 000 записей. Откуда ты взял 200 непонятно.

[quote]Где пределы для кол-ва записей выбранных selectом, при том, что я выбираю только ID и пару "коротких" полей, вроде лук-ап поля.[/quote]
Предел 50 000 записей, независимо что ты там выбираешь и сколько данных через связи подтягиваешь.

[quote]Где пределы кол-ва вставляемых и, что более важно, апдатируемых записей при тех же условиях?[/quote]
10,000 записей

[quote]Как узнать общее число записей в объекте?[/quote]
Вот тут все сложно!!!!
Есть такой запрос 
Integer count = [SELECT COUNT() FROM Contact]
он вернет тебе количество записей которые который выберет данный запрос.
НО на этот запрос тоже распространяется ограничение в 50 000 записей, т.е. если у тебя в базе больше 50000 записей получишь Exception. 
В интернете есть много workaround решений данного вопроса.

Dmitry Shnyrev
У тебя небольшой бардак в голове по поводу лимитов, извини за прямоту.

Пока так и есть. Но каждый день по-немного распутываю клубок SFDC, и время от времени сталкиваюсь с вопросами, на которые не могу найти однозначного ответа. Тогда спрашиваю знающих людей. Спасибо за ответы.

Да, действительно SELECT - это не DML, хотя в данном случае лимиты похожи.

Dmitry Shnyrev
Откуда ты взял 200 непонятно.

Вот что меня запутало (взято из APEX WORKBOOK):

"Tutorial #13: Running Apex Within Governor Execution Limits:
Use SOQL for loops to operate on records in batches of 200. This helps avoid the heap size limit of 6 MB. "

Вот теперь вижу, что речь идет-то о "heap size limit", а о том, что ко-во записей в принципе может быть 50,000, они там ни словом не обмолвились.

И далее в разделе "Tutorial #15: Apex Batch Processing" опять магическая цифра 200: "The default batch size is 200 records."

Вот это и запутало.

Но раз коснулись этой темы, то возникает вопрос: а как я могу узнать сколько записей (200, 300, 1000) определенного объекта рискует превысить "the heap size", т.е. в каких случаях нужно применять, то что они предлагают:

SOQL For Loops
Use SOQL for loops to operate on records in batches of 200. This helps avoid the heap size limit of 6 MB. Note that this limit is for code running synchronously and it is higher for asynchronous code execution.

Example: Query without a for loop
The following is an example of a SOQL query that retrieves all merchandise items and stores them in a List variable. If the returned merchandise items are large in size and a large number of them was returned, the heap size limit might be hit.

List<Merchandise__c> ml = [SELECT Id,Name FROM Merchandise__c];

Recommended Alternative: Query within a for loop

To prevent this from happening, this second version uses a SOQL for loop, which iterates over the returned results in batches of 200 records. This reduces the size of the ml list variable which now holds 200 items instead of all items in the query results, and gets recreated for every batch.

for (List<Merchandise__c> ml : [SELECT Id,Name FROM Merchandise__c]){
// Do something.
}

И когда лучше использовать Batch Apex Class?

Спасибо

[quote="Dmitry Shnyrev"]У тебя небольшой бардак в голове по поводу лимитов, извини за прямоту.[/quote]

Пока так и есть. Но каждый день по-немного распутываю клубок SFDC, и время от времени сталкиваюсь с вопросами, на которые не могу найти однозначного ответа. Тогда спрашиваю знающих людей. Спасибо за ответы.

Да, действительно SELECT - это не DML, хотя в данном случае лимиты похожи.

[quote="Dmitry Shnyrev"] Откуда ты взял 200 непонятно. [/quote]

Вот что меня запутало (взято из APEX WORKBOOK):

"Tutorial #13: Running Apex Within Governor Execution Limits:
Use SOQL for loops to operate on records in batches of 200. This helps avoid the heap size limit of 6 MB. "

Вот теперь вижу, что речь идет-то о "heap size limit", а о том, что ко-во записей в принципе может быть 50,000, они там ни словом не обмолвились.

И далее в разделе "Tutorial #15: Apex Batch Processing" опять магическая цифра 200: "The default batch size is 200 records."

Вот это и запутало.

Но раз коснулись этой темы, то возникает вопрос: а как я могу узнать сколько записей (200, 300, 1000) определенного объекта рискует превысить "the heap size", т.е. в каких случаях нужно применять, то что они предлагают:

[i][b]SOQL For Loops[/b]
Use SOQL for loops to operate on records in batches of 200. This helps avoid the heap size limit of 6 MB. Note that this limit is for code running synchronously and it is higher for asynchronous code execution.

Example: Query [b]without a for loop[/b]
The following is an example of a SOQL query that retrieves all merchandise items and stores them in a List variable. If the returned merchandise items are large in size and a large number of them was returned, the heap size limit might be hit.

List<Merchandise__c> ml = [SELECT Id,Name FROM Merchandise__c];

Recommended Alternative: Query [b]within a for loop[/b]

To prevent this from happening, this second version uses a SOQL for loop, which iterates over the returned results in batches of 200 records. This reduces the size of the ml list variable which now holds 200 items instead of all items in the query results, and gets recreated for every batch.

for (List<Merchandise__c> ml : [SELECT Id,Name FROM Merchandise__c]){
    // Do something.
}[/i]

И когда лучше использовать Batch Apex Class?

Спасибо

200 записей в туториалах Salesforce это магическое число типо к которому надо стремиться. Т.е. рекомендуемая пачка записей, с которыми нужно работать за один вызов. Конечно с теми же успехами можно выбирать и работать с 1000 записями или 10000 записей (если влезть в heap size 6мб)

Но вот давай рассуждать с точки зрения логики. Нафига человеку в определенные момент времени более 200 записей? Что он будет с ними делать? Для этого существуют всякие фильтры, пагинации и другое. Но не надо ему 1000 записей в один заход
Потом массовая обработка данных. Если ты точно не знаешь сколько тебе надо обработать данных - пытаться обработать их за один вызов - это однозначно потенциально опасный код. Для этого в Salesforce предусмотрены Batches. Они разбивают данные на пачки и обрабатывают эти пачки по очереди. Каждая пачка - это типо один вызов, каждый со своими лимитами. Вот эти пачки по умолчанию содержат по 200 записей.

В общем, 200 это своего рода магическое число, который ты можешь использовать в ходе проектирования алгоритмов.

Как-то так.

200 записей в туториалах Salesforce это магическое число :) типо к которому надо стремиться. Т.е. рекомендуемая пачка записей, с которыми нужно работать за один вызов. Конечно с теми же успехами можно выбирать и работать с 1000 записями или 10000 записей (если влезть в heap size 6мб)

Но вот давай рассуждать с точки зрения логики. Нафига человеку в определенные момент времени более 200 записей? Что он будет с ними делать? Для этого существуют всякие фильтры, пагинации и другое. Но не надо ему 1000 записей в один заход :)

Потом массовая обработка данных. Если ты точно не знаешь сколько тебе надо обработать данных - пытаться обработать их за один вызов - это однозначно потенциально опасный код. Для этого в Salesforce предусмотрены Batches. Они разбивают данные на пачки и обрабатывают эти пачки по очереди. Каждая пачка - это типо один вызов, каждый со своими лимитами. Вот эти пачки по умолчанию содержат по 200 записей. 

В общем,  200 это своего рода магическое число, который ты можешь использовать в ходе проектирования алгоритмов.

Как-то так.

Dmitry Shnyrev
Потом массовая обработка данных.

С этим и работаю сейчас. Перелинковка лук-ап полей при редизайне объектной схемы работающего приложения.
Но код готов, что делать с лимитами вроде понятно. Осталось настроить обработку исключений и готово.

[quote="Dmitry Shnyrev"]

Потом массовая обработка данных. [/quote]

С этим и работаю сейчас. Перелинковка лук-ап полей при редизайне объектной схемы работающего приложения.
Но код готов, что делать с лимитами вроде понятно. Осталось настроить обработку исключений и готово.

Den Brown
Перелинковка лук-ап полей при редизайне объектной схемы работающего приложения.

Ну если уверен, что за раз не придется обрабатывать более 10000 записей, то можно не заморачиваться :)

[quote="Den Brown"]Перелинковка лук-ап полей при редизайне объектной схемы работающего приложения.[/quote]

Ну если уверен, что за раз не придется обрабатывать более 10000 записей, то можно не заморачиваться :)

Даже, если использовать то, что рекомендуем учебник:

for (List<Merchandise__c> ml : [SELECT Id,Name FROM Merchandise__c]){
// Do something.
}

в котором предполагается что в List будут выбираться по 200 записей (я так это понял, кол-во записей нам настраивать не нужно),

то кол-во итераций в любом случае не может превышать 100, иначе будет будет превышен лимит по SELECTам.
Т.е. запускать код можно если в Merchandise__c менее 20к записей.
Тоже не плохо.

Даже, если использовать то, что рекомендуем учебник:

[i]for (List<Merchandise__c> ml : [SELECT Id,Name FROM Merchandise__c]){
// Do something.
}[/i]

в котором предполагается что в List будут выбираться по 200 записей (я так это понял, кол-во записей нам настраивать не нужно),

то кол-во итераций в любом случае не может превышать 100, иначе будет будет превышен лимит по SELECTам.
Т.е. запускать код можно если в Merchandise__c менее 20к записей.
Тоже не плохо.

Даже, если использовать то, что рекомендуем учебник:

for (List<Merchandise__c> ml : [SELECT Id,Name FROM Merchandise__c]){
// Do something.
}

в котором предполагается что в List будут выбираться по 200 записей (я так это понял, кол-во записей нам настраивать не нужно),

Den Brown, поздравляю! Ты сломал мозг мне и моим коллегам! Первый раз встречаем такую конструкцию

for (List<Merchandise__c> ml : [SELECT Id,Name FROM Merchandise__c]) {}

Вот что значит углубленно читать документацию.

Вот более полный пример

public void massUpdate() {
for (List<Merchandise__c> merchList : [SELECT Name FROM Merchandise__c]) {
for(Merchandise__c m : merchList) {
if (m.Name.contains('pen')) {
m.Price__c *= 1.1;
}
}
update merchList;
}
}

Для уменьшения heap size главный SOQL запрос разбивается на пачки по 200 записей, которые потом во внутреннем for обрабатываются. Это удобно тем, что в память сразу не загружается весь результат, а небольшими пачками. НО все равно общий результат должен уложиться в SOQL<50 000 и DML<10 000 записей как ты их не разбивай.

Если нужно больше, то только batch поможет

[quote]Даже, если использовать то, что рекомендуем учебник:

for (List<Merchandise__c> ml : [SELECT Id,Name FROM Merchandise__c]){
// Do something.
}

в котором предполагается что в List будут выбираться по 200 записей (я так это понял, кол-во записей нам настраивать не нужно),[/quote]

Den Brown, поздравляю! Ты сломал мозг мне и моим коллегам! Первый раз встречаем такую конструкцию 

for ([color=#BF0000][b]List<Merchandise__c>[/b][/color] ml : [SELECT Id,Name FROM Merchandise__c]) {}

Вот что значит углубленно читать документацию. 

Вот более полный пример
[code]public void massUpdate() {
    for (List<Merchandise__c> merchList : [SELECT Name FROM Merchandise__c]) {
        for(Merchandise__c m : merchList) {
            if (m.Name.contains('pen')) {
                m.Price__c *= 1.1;
            }
        }
        update merchList;
    }
}[/code]

Для уменьшения heap size главный SOQL запрос разбивается на пачки по 200 записей, которые потом во внутреннем for обрабатываются. Это удобно тем, что в память сразу не загружается весь результат, а небольшими пачками. НО все равно общий результат должен уложиться в SOQL<50 000 и DML<10 000 записей как ты их не разбивай.

Если нужно больше, то только batch поможет

вот в том-то и дело, что до лимита "SOQL<50 000" дело не может дойти, так как код должно выбить по лимитам на SELECT, который во внешнем цикле. А если не больше 100 selectов, то мы можем обработать не более 20,000 записей за выполнения.

Плюс, если кол-во обновленных записей суммируется (а так ли это?), то таким образом, есть еще лимит - 10,000 на кол-во апдатированных записей (хотя в одном апдейте будет не более 200 записей).

Но я не ожидаю, что кол-во записей где-то будет больще 10,000, так что все ОК.

Хотя именно сложные ситуации учат нас чему-то новому.

вот в том-то и дело, что до лимита "SOQL<50 000" дело не может дойти, так как код должно выбить по лимитам на SELECT, который во внешнем цикле. А если не больше 100 selectов, то мы можем обработать не более 20,000 записей за выполнения.

Плюс, если кол-во обновленных записей суммируется (а так ли это?), то таким образом, есть еще лимит - 10,000 на кол-во апдатированных записей (хотя в одном апдейте будет не более 200 записей).

Но я не ожидаю, что кол-во записей где-то будет больще 10,000, так что все ОК.

Хотя именно сложные ситуации учат нас чему-то новому.

Dmitry Shnyrev
public void massUpdate() {
for (List<Merchandise__c> merchList : [SELECT Name FROM Merchandise__c]) {
for(Merchandise__c m : merchList) {
if (m.Name.contains('pen')) {
m.Price__c *= 1.1;
}
}
update merchList;
}
}

Ааааа. DML-операция в цикле(((
Может все-таки не апдейтиить в цикле, дабы не полететь к чертям по лимитам?

List<List<Merchandise__c>> merchToUpdate = new List<List<Merchandise__c>>();
for (List<Merchandise__c> merchList : [SELECT Name FROM Merchandise__c]) {
for(Merchandise__c m : merchList) {
if (m.Name.contains('pen')) {
m.Price__c *= 1.1;
}
}
merchToUpdate.add(merchList);
}
/// DML update

И что-то мне подсказывает, что конструкция вида for (List<Merchandise__c> merchList : [SELECT Name FROM Merchandise__c]) все-таки не прокатит. Согласен с Дмитрием, что-то в этом коде не то))

[quote="Dmitry Shnyrev"][quote]
[code]public void massUpdate() {
    for (List<Merchandise__c> merchList : [SELECT Name FROM Merchandise__c]) {
        for(Merchandise__c m : merchList) {
            if (m.Name.contains('pen')) {
                m.Price__c *= 1.1;
            }
        }
        update merchList;
    }
}[/code]
[/quote][/quote]

Ааааа. DML-операция в цикле((( 
Может все-таки не апдейтиить в цикле, дабы не полететь к чертям по лимитам?
[code]
    List<List<Merchandise__c>> merchToUpdate = new List<List<Merchandise__c>>();
    for (List<Merchandise__c> merchList : [SELECT Name FROM Merchandise__c]) {
        for(Merchandise__c m : merchList) {
            if (m.Name.contains('pen')) {
                m.Price__c *= 1.1;
            }
        }
        merchToUpdate.add(merchList);
    }
/// DML update
[/code]

И что-то мне подсказывает, что конструкция вида for (List<Merchandise__c> merchList : [SELECT Name FROM Merchandise__c]) все-таки не прокатит. Согласен с Дмитрием, что-то в этом коде не то))

Работать будет. Это своего рода плюшка от Salesforce для разработчиков.

Про это написано здесь
Working with Very Large SOQL Queries
Tutorial #13: Running Apex Within Governor Execution Limits (последний пункт на странице)

А то что DML операция в цикле, в этом весь смысл.

Тему тяжелую ты поднял, редко по работе приходится с там сталкиваться. Так что лучше пиши проще, а если уже столкнешься с проблемой привышения лимитов по heap size - вспомнишь, что есть такой способ.

Работать будет. Это своего рода плюшка от Salesforce для разработчиков.

Про это написано здесь
[url=http://www.salesforce.com/us/developer/docs/dbcom_apex250/Content/langCon_apex_SOQL_VLSQ.htm]Working with Very Large SOQL Queries[/url]
[url=http://www.salesforce.com/us/developer/docs/apex_workbook/Content/apex_govlimits_overview.htm]Tutorial #13: Running Apex Within Governor Execution Limits[/url] (последний пункт на странице)

А то что DML операция в цикле, в этом весь смысл. 

Тему тяжелую ты поднял, редко по работе приходится с там сталкиваться. Так что лучше пиши проще, а если уже столкнешься с проблемой привышения лимитов по heap size - вспомнишь, что есть такой способ.

Dmitry Shnyrev
Так что лучше пиши проще, а если уже столкнешься с проблемой привышения лимитов по heap size - вспомнишь, что есть такой способ.

Конечно буду вначале пробовать, что проще.
Но чувствую они неспроста вышеуказанную конструкцию предлагают...

И снова вопрос из практики: если в результате массовой операции по изменнию значения какого-то поля в записях, в поле будет передаваться значение, в норме, вызывающее "сработку" тригера или Work flow action, то случиться ли эта "сработка" в нашем случае - при программном изменении значения поля?

Что делать, если оно случится, но нам оно нам не нужно? или записей так много, что система упа... нет не должна упасть.. тогда вернет ошибку?
Просто отключить тригеры и Work flow rules на время выполнения изменений?

Вопросы просто из жизни, наверняка кто-то уже сталкивался или столкнется с этим...

[quote="Dmitry Shnyrev"]Так что лучше пиши проще, а если уже столкнешься с проблемой привышения лимитов по heap size - вспомнишь, что есть такой способ.[/quote]

Конечно буду вначале  пробовать, что проще. 
Но чувствую они неспроста вышеуказанную конструкцию предлагают...

И снова вопрос из практики: если в результате массовой операции по изменнию значения какого-то поля в записях, в поле будет передаваться значение, в норме, вызывающее "сработку" тригера или Work flow action, то случиться ли эта "сработка" в нашем случае - при программном изменении значения поля?

Что делать, если оно случится, но нам оно нам не нужно? или записей так много, что система упа... нет не должна упасть.. тогда вернет ошибку?
Просто отключить тригеры и Work flow rules на время выполнения изменений?

Вопросы просто из жизни, наверняка кто-то уже сталкивался или столкнется с этим...

Триггер и воркфлоу будут срабатывать на ваши вызовы.

Я бы рекомендовал для массовой обработки данных использовать асинхронный подход APEX Batch:http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_batch_interface.htm.

Правда это следующий этап изучения платформы.

Триггер и воркфлоу будут срабатывать на ваши вызовы.
 
Я бы рекомендовал для массовой обработки данных использовать асинхронный подход APEX Batch:[url]http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_batch_interface.htm[/url].

Правда это следующий этап изучения платформы.

Den Brown
Что делать, если оно случится, но нам оно нам не нужно? или записей так много, что система упа... нет не должна упасть.. тогда вернет ошибку?
Просто отключить тригеры и Work flow rules на время выполнения изменений?
.

Отключать я бы не рекомендовал. Тут стоит пересмотреть свою бизнес-логику, возможно, в данной ситуации вам не нужно использовать workflow или trigger и/или не заполнять те поля, которые вызывают сработку триггера/воркфлоу.

Если все же наличие воркфлоу и триггера необходимо, то я бы рекомендовал в логике триггера делать проверки....а также пересмотреть условия для воркфлоу.

Den Brown, если есть конкретная постановка задачи, то выноси на суд...оценим все решения - выберем лучшее)

[quote="Den Brown"]
Что делать, если оно случится, но нам оно нам не нужно? или записей так много, что система упа... нет не должна упасть.. тогда вернет ошибку?
Просто отключить тригеры и Work flow rules на время выполнения изменений?
.[/quote]

Отключать я бы не рекомендовал. Тут стоит пересмотреть свою бизнес-логику, возможно, в данной ситуации вам не нужно использовать workflow или trigger и/или не заполнять те поля, которые вызывают сработку триггера/воркфлоу. 

Если все же наличие воркфлоу и триггера необходимо, то я бы рекомендовал в логике триггера делать проверки....а также пересмотреть условия для воркфлоу.

Den Brown, если есть конкретная постановка задачи, то выноси на суд...оценим все решения - выберем лучшее)

Den Brown
И снова вопрос из практики: если в результате массовой операции по изменнию значения какого-то поля в записях, в поле будет передаваться значение, в норме, вызывающее "сработку" тригера или Work flow action, то случиться ли эта "сработка" в нашем случае - при программном изменении значения поля?

Что делать, если оно случится, но нам оно нам не нужно? или записей так много, что система упа... нет не должна упасть.. тогда вернет ошибку?
Просто отключить тригеры и Work flow rules на время выполнения изменений?

Триггеры и workflow срабатывают в ответ на любую попытку изменить что-то в базе данных. Это не зависит откуда ты это делаешь - из кода или со страницы в браузере.

Отключить триггеры или workflow программно (на время) нельзя. Т.е. они будут всегда срабатывать.

Если в случае массовой обработки данных есть вероятность что все "упадет", то, как правильно отметил Art Vegas, надо смотреть в сторону асинхронной обработки данных, а точнее batch.

Действительно, опиши задачу здесь - будет проще разговаривать!

[quote="Den Brown"]И снова вопрос из практики: если в результате массовой операции по изменнию значения какого-то поля в записях, в поле будет передаваться значение, в норме, вызывающее "сработку" тригера или Work flow action, то случиться ли эта "сработка" в нашем случае - при программном изменении значения поля?

Что делать, если оно случится, но нам оно нам не нужно? или записей так много, что система упа... нет не должна упасть.. тогда вернет ошибку?
Просто отключить тригеры и Work flow rules на время выполнения изменений?[/quote]

Триггеры и workflow срабатывают в ответ на любую попытку изменить что-то в базе данных. Это не зависит откуда ты это делаешь - из кода или со страницы в браузере.

Отключить триггеры или workflow программно (на время) нельзя. Т.е. они будут всегда срабатывать.

Если в случае массовой обработки данных есть вероятность что все "упадет", то, как правильно отметил Art Vegas, надо смотреть в сторону асинхронной обработки данных, а точнее batch.

Действительно, опиши задачу здесь - будет проще разговаривать!

batch interface - это однозначно, то что нужно будет осваивать.

у меня ситуация проста как в учебнике: в одном объекте ест поле "Статус" с пик-листом, и вот поступила просьба, чтобы программно выставить в нескольких тысячах записей определенного периода времени это поле в значение "Закрыто".

Базовый код готов. Работает на небольшом кол-ве записей. Сегодня буду тестировать на несколько тысячах. Если будут проблемы с простым кодом - то попробую код с циклом по 200 записей. Ну если и с ним проблемы - то batch interface.

Но дело в том, что на изменение Статус в Закрыто там наверняка есть какое-то действие. Сейчас буду смотреть это.

Но вопрос в принципе можно задавить уже: если там есть тригер or WFAciton - будет ли сработка при программном изменении значения поля (пока писал это сообщение - Дмитрий уже ответил)? А если изменяются тысячи записей - будет ли ошибка выполнения кода по лимитам из-за сработки тригеров? (Планирую отключать тригер на время выполнения программы - если это потребуется - не програмно, а как обычно)

Я планирую сегодня методом проб и тестом разобраться с этим, но если у кого-то уже есть опыт с этим - то может пригодится.

batch interface - это однозначно, то что нужно будет осваивать.

у меня ситуация проста как в учебнике: в одном объекте ест поле "Статус" с пик-листом, и вот поступила просьба, чтобы программно выставить в нескольких тысячах записей определенного периода времени это поле в значение "Закрыто".

Базовый код готов. Работает на небольшом кол-ве записей. Сегодня буду тестировать на несколько тысячах. Если будут проблемы с простым кодом - то попробую код с циклом по 200 записей. Ну если и с ним проблемы - то batch interface.

Но дело в том, что на изменение Статус в Закрыто там наверняка есть какое-то действие. Сейчас буду смотреть это. 

Но вопрос в принципе можно задавить уже: если там есть тригер or WFAciton - будет ли сработка при программном изменении значения поля (пока писал это сообщение - Дмитрий уже ответил)? А если изменяются тысячи записей - будет ли ошибка выполнения кода по лимитам из-за сработки тригеров? (Планирую отключать тригер на время выполнения программы - если это потребуется - не програмно, а как обычно)

Я планирую сегодня методом проб и тестом разобраться с этим, но если у кого-то уже есть опыт с этим - то может пригодится.

Практически все существующие лимиты салесфорса преодолимы тем или иным образом. Даже лимит а 50.000 записей можно преодолеть без использования батча.

Практически все существующие лимиты салесфорса преодолимы тем или иным образом. Даже лимит а 50.000 записей можно преодолеть без использования батча.

wilder
Практически все существующие лимиты салесфорса преодолимы тем или иным образом. Даже лимит а 50.000 записей можно преодолеть без использования батча.

Да, согласен, есть способы обхода и связаны они с использованием Javascript на стороне клиента в основном.

Но смысл говорить общим фразами :)? я думаю, что стоит привести пару реальных примеров из реальной жизни и обсудить их.

Хотя я не устаю повторять - лимиты salesforce не с потолка взяты, и они позволяют решить любые реальные задачи бизнеса.
Обычно, когда у меня появляется возможность вылезти за пределы лимитов, я смотрю на задачу и понимаю что все проблемы в ней, а не в Salesforce!!!

[quote="wilder"]Практически все существующие лимиты салесфорса преодолимы тем или иным образом. Даже лимит а 50.000 записей можно преодолеть без использования батча.[/quote]

Да, согласен, есть способы обхода и связаны они с использованием Javascript на стороне клиента в основном.

Но смысл говорить общим фразами :)? я думаю, что стоит привести пару реальных примеров из реальной жизни и обсудить их.

Хотя я не устаю повторять - лимиты salesforce не с потолка взяты, и они позволяют решить любые реальные задачи бизнеса. 
Обычно, когда у меня появляется возможность вылезти за пределы лимитов, я смотрю на задачу и понимаю что все проблемы в ней, а не в Salesforce!!!

Dmitry Shnyrev
Да, согласен, есть способы обхода и связаны они с использованием Javascript на стороне клиента в основном.

Но смысл говорить общим фразами :)? я думаю, что стоит привести пару реальных примеров из реальной жизни и обсудить их.

Хотя я не устаю повторять - лимиты salesforce не с потолка взяты, и они позволяют решить любые реальные задачи бизнеса.
Обычно, когда у меня появляется возможность вылезти за пределы лимитов, я смотрю на задачу и понимаю что все проблемы в ней, а не в Salesforce!!!

Немного оффтопа в разжигание дискуссий.

Например, лимит в 4 000 000 символов на орге для Apex Classes можно преодолеть, докупив еще место на орге;)

[quote="Dmitry Shnyrev"]

Да, согласен, есть способы обхода и связаны они с использованием Javascript на стороне клиента в основном.

Но смысл говорить общим фразами :)? я думаю, что стоит привести пару реальных примеров из реальной жизни и обсудить их.

Хотя я не устаю повторять - лимиты salesforce не с потолка взяты, и они позволяют решить любые реальные задачи бизнеса. 
Обычно, когда у меня появляется возможность вылезти за пределы лимитов, я смотрю на задачу и понимаю что все проблемы в ней, а не в Salesforce!!![/quote]

Немного оффтопа в разжигание дискуссий.

Например, лимит в 4 000 000 символов на орге для Apex Classes можно преодолеть, докупив еще место на орге;)

Как я помню (недавно мы столкнулись с данной проблемой на одном дев орге), лимит был 3 000 000 символов.
Если я неправ, то исправьте.

В документации я нашел следующее:

Size-Specific Apex Limits

Maximum number of characters for a class 1 million
Maximum number of characters for a trigger 1 million
Maximum amount of code used by all Apex code in an organization (1) 3 MB
Method size limit (2) 65,535 bytecode instructions in compiled form

(1) This limit does not apply to certified managed packages installed from AppExchange (that is, an app that has been marked AppExchange Certified). The code in those types of packages belong to a namespace unique from the code in your organization. For more information on AppExchange Certified packages, see the Force.com AppExchange online help. This limit also does not apply to any code included in a class defined with the @isTest annotation.
(2) Large methods that exceed the allowed limit cause an exception to be thrown during the execution of your code.

Как я помню (недавно мы столкнулись с данной проблемой на одном дев орге), лимит был 3 000 000 символов.
Если я неправ, то исправьте.

В документации я нашел следующее:

[quote]Size-Specific Apex Limits

Maximum number of characters for a class	1 million
Maximum number of characters for a trigger	1 million
Maximum amount of code used by all Apex code in an organization (1)	3 MB
Method size limit (2)	65,535 bytecode instructions in compiled form

(1) This limit does not apply to certified managed packages installed from AppExchange (that is, an app that has been marked AppExchange Certified). The code in those types of packages belong to a namespace unique from the code in your organization. For more information on AppExchange Certified packages, see the Force.com AppExchange online help. This limit also does not apply to any code included in a class defined with the @isTest annotation.
(2) Large methods that exceed the allowed limit cause an exception to be thrown during the execution of your code.[/quote]

Всем привет!

Также совсем недавно столкнулся с проблемой.

Задача передать очень большее количество информации по HTTP.
Проверил все опытным путем.
Оказалось в теле POST можно отправить около 54 мб. Если кому-то полезно будет такая информация... Больше увы - падает по лимитам. В сети накопать информации не смог. Разве, что с VF странички можно загрузки файл не более 10 мб.

Примечание: Проверял через cURL.

Всем привет!

Также совсем недавно столкнулся с проблемой.

Задача передать очень большее количество информации по HTTP. 
Проверил все опытным путем. 
Оказалось в теле POST можно отправить около 54 мб. Если кому-то полезно будет такая информация... Больше увы - падает по лимитам. В сети накопать информации не смог. Разве, что с VF странички можно загрузки файл не более 10 мб.

Примечание: Проверял через cURL.

Если есть возможность то можно разбить на пакеты, скажем по 3 мегабайта.


Я вот пытаюсь уже почти 2 года победить салесфорс с лимитом на прием. Больше 3 мегабайт нельзя. Почему ? никто объяснить не может

Если есть возможность то можно разбить на пакеты, скажем по 3 мегабайта.


Я вот пытаюсь уже почти 2 года победить салесфорс с лимитом на прием. Больше 3 мегабайт нельзя. Почему ? никто объяснить не может

Учитывая крайне ограниченную возможность работы SF большими объемами данных и файлами, то стоит сразу посмотреть в сторону сторонних платформ. Тот же Heroku если нужно организовать сложную логику работы с данными (тем более что он сейчас под Salesforce находится и имеет какой-то специальный API для интреграции) или хранилище Amazon. Все равно в итоге выйдет дешевле, чем ломать голову от salesforce и докупать дисковое пространство, которое не такое уж и дешевое.
На некоторых наших проектах так и сделано (wilder не даст соврать)

Кстати wilder, можно вопрос, в новых проектах с которыми тебе пришлось столкнуться есть ли работа с большими файлами и как она организована?

Учитывая крайне ограниченную возможность работы SF большими объемами данных и файлами, то стоит сразу посмотреть в сторону сторонних платформ. Тот же Heroku если нужно организовать сложную логику работы с данными (тем более что он сейчас под Salesforce находится  и имеет какой-то специальный API для интреграции) или хранилище Amazon. Все равно в итоге выйдет дешевле, чем ломать голову от salesforce и докупать дисковое пространство, которое не такое уж и дешевое.
На некоторых наших проектах так и сделано (wilder не даст соврать)

Кстати wilder, можно вопрос, в новых проектах с которыми тебе пришлось столкнуться есть ли работа с большими файлами и как она организована?

Dmitry Shnyrev
Учитывая крайне ограниченную возможность работы SF большими объемами данных и файлами, то стоит сразу посмотреть в сторону сторонних платформ. Тот же Heroku если нужно организовать сложную логику работы с данными (тем более что он сейчас под Salesforce находится и имеет какой-то специальный API для интреграции) или хранилище Amazon. Все равно в итоге выйдет дешевле, чем ломать голову от salesforce и докупать дисковое пространство, которое не такое уж и дешевое.
На некоторых наших проектах так и сделано (wilder не даст соврать)

Кстати wilder, можно вопрос, в новых проектах с которыми тебе пришлось столкнуться есть ли работа с большими файлами и как она организована?

Смотря что понимать под большими файлами. Например в одном из последних проектов пришлось работать с медицинскими файлами размером 200-300 мегабайт. Эти файлы хранятся на внешнем сервере, а в салесфорсе хранятся только Id для доступа к этим файлам. А все необходимые операции происходят на стороне клиента.

Так же есть какой-то нативный пакет для салесфорса, который реализует примерно такой-же функционал

[quote="Dmitry Shnyrev"]Учитывая крайне ограниченную возможность работы SF большими объемами данных и файлами, то стоит сразу посмотреть в сторону сторонних платформ. Тот же Heroku если нужно организовать сложную логику работы с данными (тем более что он сейчас под Salesforce находится  и имеет какой-то специальный API для интреграции) или хранилище Amazon. Все равно в итоге выйдет дешевле, чем ломать голову от salesforce и докупать дисковое пространство, которое не такое уж и дешевое.
На некоторых наших проектах так и сделано (wilder не даст соврать)

Кстати wilder, можно вопрос, в новых проектах с которыми тебе пришлось столкнуться есть ли работа с большими файлами и как она организована?[/quote]

Смотря что понимать под большими файлами. Например в одном из последних проектов пришлось работать с медицинскими файлами размером 200-300 мегабайт. Эти файлы хранятся на внешнем сервере, а в салесфорсе хранятся только Id для доступа к этим файлам. А все необходимые операции происходят на стороне клиента.

Так же есть какой-то нативный пакет для салесфорса, который реализует примерно такой-же функционал