Versions Compared

Old Version 2

changes.mady.by.user Jonathan Muse

Saved on

compared with

New Version Current

changes.mady.by.user Jonathan Muse

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Button handy
blanktrue
color#0052CC
nameSend Feedback
linkhttps://docs.google.com/forms/d/e/1FAIpQLScmToBe3vynAlb5fdKwCGxYqnTbDc66sIBgeecG2BuFDuHc7g/viewform?entry.2002826954=Script+Storage+-+490996090
widthauto

Excerpt
hiddentrue

Virtualization of a SIL™ script' means that a script may be stored either on disk (default) or in the database (optional).

'Virtualization of a SIL™ script' means that a script may be stored either on disk (default) or in the database (optional).

This may seem like an odd functionality, but in short time, we're preparing a bold move: carrying the whole scripts to the database, performing a backup on the server, then moving to another one and doing restore, that will restore all the scripts in the right places. You will have the opportunity to move them back to files on the target system. This functionality is the first step toward this goal.

In addition to the architecture that is flexible enough so we can add any type of storage, storing files in the database is very important feature.

SIL Home Directory

The most important, the SIL™ Home Directory indicates the path on the server that is used to store your programs. That directory must exist and the default is created when our apps are first installed. Charset represents the charset used when your programs are stored and interpreted. It is the default charset, and is used in all the text file operations if not specified otherwise.

Contents

Table of Contents
minLevel1
maxLevel1

Database Storage

Advantages of Storing Scripts in the Database

  • Files management in case of moving an installation

  • Theoretically safer storage (we hope you backup your database)

  • Disk remains clean

Disadvantages of Storing Scripts in the Database

  • Accessing a source before putting it to the cache has a small performance penalty

  • Accessing it outside of our SIL™ editor may be harder

Disk Storage

Advantages of Storing Scripts on the File System

  • Scripts can be versioned and backed up by using a Git repository on the file system

  • Script performance is generally faster

  • Scripts are easier to access

Disadvantages of Storing Scripts on the File System

  • Scripts may be less secure (not that it may be an issue)

  • Slightly harder to migrate

So which one should I choose?

Generally, we suggest you go with the file system. Its faster and easy. There can be more advantages to being able to access the file system that just storing scripts, but that is for another guide.

However…

Info

If the file system is not configured to 100% Atlassian’s guidelines the nodes may be slow to share files across them. Most of the time this is not an issue and users do not notice. However, when editing scripts across the nodes it may take a few seconds for them to propagate. Storing the scripts in the database may help alleviate some of those issues.

Configuring Script Storage

Power Apps Configuration → General → SIL Storage

The above setting is used just for files that will be created. Files may be individually moved between storages using the SIL Manager editor. If unsure, use File System.

Note

Important

Only SIL™ scripts are stored in the database storage as of now. Other configuration files, like mail templates, are not. We plan to change that, too.

Switching Storage Types

New to SIL 5.x, a utility has been added to migrate the scripts between the database and the file system. Please not the above warning, only SIL scripts are stored in the database. It is common for experienced scripters to use many other types of files like, HTML, JavaScript, CSV, text, etc.

More Configuration Guides

Filter by label (Content by label)
showLabelsfalse
showSpacefalse
cqllabel = "configuration" and space = currentSpace ( )

We've encountered an issue exporting this macro. Please try exporting this page again later.