Fixed
Status Update
No update yet.
Comments
se...@google.com
Hi,
This behavior has been fixed.
Regards.
am...@var.fr
When your fix will be applied in Prod ?
[Deleted User] <[Deleted User]>
I can confirm that I am still experience this issue (literally 20 minute runtime for some queries than run in less than 1 minute in my local environment). So I repeat the same question as above: is this fix in Production, and if not, when can we expect it to be deployed?
am...@var.fr
Samething to me.. I need to know when the fix will be deployed.... You have to give us a roadmap, at least t know what to do with our applications...
ad...@motorolasolutions.com
Comment has been deleted.
ga...@hakesbrothers.com
We are having the same issue with speed. We utilize the GCP MySQL Database using Stored Procedures. When I run them directly thru the SQL Tool on my desktop it takes 20-30 seconds to run, but using JDBC in my appscript within a Google Sheet takes like 5-6 minutes.
UPDATE: Unchecked
Enable Chrome V8 runtime checkbox and re-saved my appscript - and now what was talking 5-6 minutes but sometimes longer now finishes in less than 2 minutes every time.
UPDATE: Unchecked
Enable Chrome V8 runtime checkbox and re-saved my appscript - and now what was talking 5-6 minutes but sometimes longer now finishes in less than 2 minutes every time.
am...@var.fr
It still so slow in comparaison of sql tool.
dm...@wurkspaces.dev
Still not working! The issue seems to come from the iterator rather than the databases, `results.next()` is taking forever...
am...@var.fr
i can also confirm that the performance issue still not resolved.
JP...@clairescourt.net
me too. Currently operating under V8 makes most of my routines non-viable.
On Thu, 26 Jan 2023 at 08:53, <buganizer-system@google.com> wrote:
On Thu, 26 Jan 2023 at 08:53, <buganizer-system@google.com> wrote:
--
John Carr
Data Manager
Tel - 01628 327614
--
Claires Court
Schools Ltd. Registered in England No. 3680796
Registered Office: 1
College Avenue, Maidenhead SL6 6AW
This message is private and
confidential. If you have received this message in error, please notify us
and remove it from your system. Any views or opinions expressed are solely
those of the author and do not necessarily represent those of Claires Court
Schools Limited
sb...@google.com
is...@google.com
pa...@pcg.io
I have the same issue with the resultset iterator speed is extremely slow.
Would be really great if fixed.
Would be really great if fixed.
ju...@gmail.com
Me encuentro con el mismo problema de JDBC, los tiempos en V8 son muy lentos, seria estupendo si se arreglara.
co...@gmail.com
is there a fix in the works i just discovered this issue. I found that if I turn off the V8 runtime my SQL pulls the data in about 10 seconds. If I turn on the V8 runtime it takes a little over 5 minutes to pull the exact same data. the snippets below are executing the same code 1 with V8 enabled 1 without V8 enabled.
am...@var.fr
Do you have any news about this issue ? We need a fix...
JP...@clairescourt.net
Agreed, this has been outstanding for such a long time. It makes many of my
routines unusable.
Also Google has the annoying habit of migrating sheets to use V8 silently
so things stop working without notice.
Thanks and regards
On Mon, 12 Jun 2023 at 08:43, <buganizer-system@google.com> wrote:
routines unusable.
Also Google has the annoying habit of migrating sheets to use V8 silently
so things stop working without notice.
Thanks and regards
On Mon, 12 Jun 2023 at 08:43, <buganizer-system@google.com> wrote:
--
John Carr
Data Manager
Tel - 01628 327614
--
Claires Court
Schools Ltd. Registered in England No. 3680796
Registered Office: 1
College Avenue, Maidenhead SL6 6AW
This message is private and
confidential. If you have received this message in error, please notify us
and remove it from your system. Any views or opinions expressed are solely
those of the author and do not necessarily represent those of Claires Court
Schools Limited
lu...@nextories.com
Same here.
Have to disable V8 on all my scripts using JDBC.
Have to disable V8 on all my scripts using JDBC.
jp...@google.com
jp...@google.com
I am marking this issue as FIXED as the internally reported issue has been marked as FIXED. Please note that there may be a delay in rolling this out to production. Thank you for your patience and please comment here if the issue remains.
co...@gmail.com
Can you confirm if it has been rolled out yet to production? I am still having the same issue.
jp...@google.com
jp...@google.com
I am marking this issue as FIXED as the internally reported issue has been marked as FIXED. Please note that there may be a delay in rolling this out to production. Thank you for your patience and please comment here if the issue remains.
jp...@google.com
Silly automation. :(
Can you reopen with a fully reproducible example? Thanks!
ad...@gmail.com
Has this been rolled out to production? Or should we wait to test again? I would like to test on production once it has been rolled out if you have an ETA for the rollout?
Thanks,
Thanks,
jp...@google.com
It was stated that it was rolled out in July 2022 however there are multiple things going on in this issue. Let's split them up and include a minimal code sample for each if it persists. Thanks for your patience in addressing the issue backlog!
ad...@gmail.com
Below is an example function that takes nearly 30 seconds to execute on the new runtime but takes less than one second on the old deprecated runtime. The connection is being made to the Cloud SQL instance in google cloud using the SSL authentication. There are 1500 entries in the result set and as someone pointed out earlier, the issue seems to be with the results.next() taking a long time in the below code.
function pullNameList() {
try {
var conn = getDBSSLConnection() //our function to get DB connection using SSL auth to cloud SQL
var stmt = conn.prepareStatement('SELECT DISTINCT name FROM names order by name asc');
var results = stmt.executeQuery();
var numCols = results.getMetaData().getColumnCount();
var data = [];
while (results.next()) {
data.push(results.getString(1));
}
results.close();
stmt.close();
return JSON.stringify(data);
} catch (e) {
throw "DB operation failed due to" + e.toString();
return "FAILED";
}
}
function pullNameList() {
try {
var conn = getDBSSLConnection() //our function to get DB connection using SSL auth to cloud SQL
var stmt = conn.prepareStatement('SELECT DISTINCT name FROM names order by name asc');
var results = stmt.executeQuery();
var numCols = results.getMetaData().getColumnCount();
var data = [];
while (results.next()) {
data.push(results.getString(1));
}
results.close();
stmt.close();
return JSON.stringify(data);
} catch (e) {
throw "DB operation failed due to" + e.toString();
return "FAILED";
}
}
pa...@pcg.io
still not fixed... the results.next() (resultset.next()) iteration sometimes needs extremely long time...
am...@var.fr
I confirm that it still not fixed. Alot of time out...
jp...@google.com
Tracking the results.next() iteration issue in
ss...@gmail.com
I use an external library that handles requests and provides asynchronous support:
https://github.com/githnow/JdbcX .
Give it a try.
Give it a try.
ag...@galenvs.com
January 2025 - almost 3 years later. Issue still persists. This is preventing me from migrating my scripts to the V8 runtime, as the JDBC results.next() iterator in V8 is basically unusable. I wish we could get some sort of status update!
ad...@gmail.com
I am confident google has abandoned the apps script platform. We should look to migrating away from it if this is the level of support.
jp...@google.com
I am confident google has abandoned the apps script platform. We should look to migrating away from it if this is the level of support.
You are confidently incorrect.
JDBC performance in Apps Script has additional overhead due to the change to V8 from Rhino. Rhino, a Java execution engine, has better performance for executing Java libraries than the translations required for V8 to do the same which adds overhead. This is expected and the benefits for using V8 over Rhino are obvious for nearly all users.
JDBC is not a priority for most Apps Script users and you can create your own REST layer or use a database HTTP plugins and UrlFetchApp.
ad...@gmail.com
I would disagree with this part
"JDBC is not a priority for most Apps Script users", but perhaps I'm in the biased minority of customers still hanging on and most have moved on.
That being said, is the official directive from google this? "JDBC is not a priority for most Apps Script users and you can create your own REST layer or use a database HTTP plugins and UrlFetchApp." While I appreciate the technical explanation you provided above for the performance issues, it does not solve the performance issues we see with JDBC in V8 and it is unusable in its current state as outlined by the users in the thread above.
If the official directive is that we should be using alternative means of communications like what you suggested with REST layer or plugins we should update the docs to reflect that. (https://developers.google.com/apps-script/guides/jdbc ) I would say either officially deprecate the support or keep it but fix the performance issues. I see this thread is marked as "fixed" but nothing has changed in our testing.
"JDBC is not a priority for most Apps Script users", but perhaps I'm in the biased minority of customers still hanging on and most have moved on.
That being said, is the official directive from google this? "JDBC is not a priority for most Apps Script users and you can create your own REST layer or use a database HTTP plugins and UrlFetchApp." While I appreciate the technical explanation you provided above for the performance issues, it does not solve the performance issues we see with JDBC in V8 and it is unusable in its current state as outlined by the users in the thread above.
If the official directive is that we should be using alternative means of communications like what you suggested with REST layer or plugins we should update the docs to reflect that. (
cr...@taggart-intl.com
I, too, use JDBC for database connectivity in numerous scripts our organization uses on a daily basis. For us to do something different and move to some other connectivity method would be a huge undertaking. For me this IS a priority.
JP...@clairescourt.net
I agree, having, in good faith, developed greater than 500 scripts that run
daily, having to move to an alternative would be a very bad reflection on
Google's attitude to their users who adopt and promote their products.
On Mon, 6 Jan 2025 at 20:33, <buganizer-system@google.com> wrote:
daily, having to move to an alternative would be a very bad reflection on
Google's attitude to their users who adopt and promote their products.
On Mon, 6 Jan 2025 at 20:33, <buganizer-system@google.com> wrote:
--
John Carr
Data Manager
Tel - 01628 327614
<
--
Claires Court
Schools Ltd. Registered in England No. 3680796
Registered Office: 1
College Avenue, Maidenhead SL6 6AW
This message is private and
confidential. If you have received this message in error, please notify us
and remove it from your system. Any views or opinions expressed are solely
those of the author and do not necessarily represent those of Claires Court
Schools Limited
Description
A short description of the issue:
Many users have reported performance issues as the ones on
This is being created to track the performance issues