General Problems with DSO -

Hi Guys,

Wondering if anyone in the Skuid Team can maybe assist with a bunch of issues / limitations found using DSO

It seems this is an underused feature and maybe at the same time I can be the guinea pig to help fix /update certain features

We are using PostgreSQL

Examples:

Made a post on this a little while back, but Skuid for some reason handles weird any ID field longer than 17 digits from DSO. see http://community.skuid.com/discussion/8012662/issue-with-dso-postgresql-unique-id-field#latest

If table unique ID not really unique, Skuid skips those ‘Rows’ when displaying (related to issue above)

A Lot of Timeout issues, not displaying on skuid page (only visible in console)

Aggregate Grouping missing all functions (calendar month…) and even trying through XML does not work

Even if in DSO some fields are made sortable, the only way to actually make field sortable is via XML

Table/Field Permissions much better in latest update, but maybe an option to give access to all Data in 1 click?

As well table/object permissions under ‘Access Control’ still not displaying proper data (create, read, update, delete) without going in each profile

And a Bunch of other little things that do not come to mind at the moment.

If someone can help , I can compile maybe a more complete list

Thank you

Hey Dave,

Apologies for the delay.

The issue you are seeing with your ID fields is actually a rounding issue we are seeing in the application with numeric fields longer than 17 digits. We are pursuing this issue now and will update you as it reaches a conclusion.

The aggregate grouping was actually recently identified as an area that needs improvement. I will let you know if i discover any functional workarounds in the meantime.

The DSO sorting issue has been reported, but for now i believe i have a few ways it can be done— one by using a template field, which should give you an option to sort (see photo), and the other by adding allowordering=“true” to the field tag in the xml.

ex:

thank you for the suggestions on the permissions setup. that section continues to be revised and updated, so i will make sure to pass your suggestions on to the team working on that UI.

as for the timeout issues im going to need more detail on what specifically was occurring when this happened. there are usually ways out of timeout, but how that is done is typically case by case.

Thank you for the update Jacob

Good to know i’m not going crazy with the 17+ digits rounding down lol

And the aggregate grouping, glad to hear it’s on the roadmap, hopefully soon

But if you can find any workaround I would really appreciate. I tried adding the CalendarMonth Function via XML, but ti did not work.

Regarding Timeout, it seems that maybe skuid has same limitation than salesforce that an api call can be max X Seconds?

as if i try to load too much data at once (still a lot less than i do on some Salesforce based skuid pages) it always times-out

The Solution i’m using right now, is call only a few models on page load,and those model’s action query other models when queried, but that make page load very slow (sometimes up to 2 min) and my biggest problem with it, Is i found no way to block the UI until all loaded. So users see partial data loaded, slowly slowly and don’t know when it’s actually finished loading all.(probably can be done via JS, but i’m a JS noob :D)

If you want i would gladly have a screenshare with you anytime

Thank you!

No Problem!

You are correct, Skuid on Salesforce is beholden to all the limitations of Salesforce including the timeouts.

With that in mind I believe the solution you are using now, with the cascading queries, is probably the correct one for this situation. However 2 minutes is a very long time for a page to load. How much data is being retrieved? It might be worth pursuing testing, extensive testing, both in and outside of Skuid to try to locate any potential issues if the data retrieved is minimal.

If the data quantity is large sometimes it can be helpful to minimize the data needed by the UI immediately to allow the rest of it to be loaded in the background, or on demand by the user. this can make a process slightly slower but the overall page faster.

if your users are alright with the load time you can probably get the UI block working declaratively by minimizing usage of both the block and unblock actions in the framework. For a long UI block I like to set one indefinite one at the start of the initial action sequence/page load, and then one unblock at the end of the final action sequence to be initiated. often if you have multiple unblocks and blocks in a cascade of sequences they end up ‘stepping’ on each other and leaving the screen blocked too little.