You have been redirected from an outdated version of the article. Below is the content available on this topic. To view the old article click here.

Schema

fig

You can add new properties (which are called “local attributes” to distinguish them from remote attributes) by entering a property (JSON) name and setting the type.

  • JSON Name: The primary JSON key to reference a property
  • DB Name: Optional name of the database property if different from the JSON key
  • Type: Internal data type
  • Format: You can set a format on Date or Double properties for output formatting. Note that starting with 1.0.RC3, there are more complex attribute types like Function, Counter, Notion, Cypher. The active code for these types has to be entered in the Format column.
  • Not Null: If set, the value must not be null
  • Unique: If set, the value must be unique
  • Default: Default value for this property

You can declare Custom Methods in dynamic schema entities which allows you to specify behaviour / business logic in a functional way.

A “view” in Structr is a set of local and remote properties that is bound to a name and can be accessed via REST. Entity types can have an arbitrary number of views that can contain different properties. You can select a view by appending its name to a REST URL. The default view is selected automatically if you don’t supply a view name in the REST URL.

URL View
/projects default
/projects/c539c26cc20e4e33b66e99a2ac031457 default
/projects/appData appData
/projects/c539c26cc20e4e33b66e99a2ac031457/webApp webApp
Example
Let's assume we have defined a "Project" entity with the properties "name", "members" and "title", all of which should be included in the default view, so we define the default view like this:
Name Attributes
default name, members, title

Please note that in the recent versions of Structr, you have to explicitly declare the properties that the default view should contain.

You can define relations between custom node types by connecting them by an arrow, starting at the dot at the bottom of a schema node and stop at the dot at the bottom of another one, or - if you want to self-relation - of the same node.

When you have successfully established a relation, you should enter relationship type (typically in all-uppercase/underscore notation, see https://gist.github.com/nigelsmall/9366313) and set the cardinality to reflect your data model.

  • Relationship Type: Mandatory identifier to tag relationships with a common semantic
  • Cardinality: Set to 1:*, *:1 or : (default)

For each relation defined between node types, a property will be automatically created for both, source and target node type. The default name will be auto-generated based on the source and target node type and the relationship type.

You can overwrite the default name by entering a new, custom name into the name column.
The Schema Editor allows you to extend the built-in data model or schema with custom data types by either creating new node types one by one, or importing Cypher code, f.e. contained in a GraphGist.

There are buttons to expand and collapse the schema nodes. The details view opens when you click on the edit icon. Please note that since 1.0.RC3, you can also edit schema relationship properties.

You can import a GraphGist to initially load data into Structr and let Structr read and analyze the data model from the GraphGist code to create an initial schema in Structr. To import a GraphGist, copy its raw URL and paste it into the designated form field.
The raw URL is what’s in your browser’s URL field when you see the AsciiDoc source code in the browser’s main area.
Structr takes care for indexing node and relationship properties in the internal Lucene indexes.

Clicking on the Rebuild Index button triggers a maintenance command, running in the background on the server, which rebuilds all these indexes.
If you want so start over with your schema creation, you can use the Clear Schema button to erase all dynamic schema information.

Please note that it won’t delete neither the static, built-in schema definitions, nor data nodes and relationships.
After importing new nodes into Structr, you need to add UUIDs to make them visible for and usable with Structr.

The Add UUIDs button triggers a maintenance command which runs in the background.

This function is available for admin users only.
The Admin Tools dialog provides some handy functions for administration of data stored in Structr like

  • Rebuild index
  • Clear schema
  • Add UUIDs
    In Structr, you can define an application-level schema which holds all information about your data model. At runtime, the schema is represented as Java POJOs as it provides the best performance possible. The primary source of the schema are the built-in classes contained in the different modules structr-core, structr-rest and structr-ui.

To extend the built-in data model or schema, it is possible to create custom data types by adding schema nodes and relationships to the underlying graph database. All graph objects can be modified at runtime, so it is possible to modify the custom schema information at runtime, too. On each modification of the in-graph schema, a process reads all schema nodes and relationships, creates Java source code which is then compiled, and the result is loaded dynamically into the running JVM. There’s no functional or performance difference between the built-in classes and the classes created from the schema graph.

Search results for "Schema"

Resource Access Grants

INFO org.structr.web.auth.UiAuthenticator - Resource access grant found for signature 'SchemaType', but method 'GET' not allowed for public users.
INFO org.structr.web.auth.UiAuthenticator - No resource access grant found for signature 'SchemaType/_Public' (URI: /structr/rest/SchemaType/public)

in newer versions:
INFO org.structr.web.auth.UiAuthenticator - Found no resource access grant for user 'john' and signature 'SchemaType' (URI: /structr/rest/SchemaType)
INFO org.structr.web.auth.UiAuthenticator - Found 1 resource access grant for anonymous users and signature 'SchemaType' (URI: /structr/rest/SchemaType), but method 'GET' not allowed in any of them.

List of REST Endpoints

URL Description Supported methods
/structr/rest/_env Structr runtime environment information GET
/structr/rest/_schema Schema information endpoint GET
/structr/rest/_schemaJson Schema JSON output endpoint GET, POST
/structr/rest/cypher Direct Cypher query endpoint GET, POST
/structr/rest/globalSchemaMethods/... Root path for global schema method execution POST
/structr/rest/login Login endpoint POST
/structr/rest/logout Logout endpoint POST
/structr/rest/token JWT endpoint POST
/structr/rest/maintenance Root path for maintenance command execution POST
/structr/rest/registration Endpoint for the User Self-Registration process POST
/structr/rest/reset-password Endpoint for the Reset Password process POST

Simple Data Model

Changing the schema definition, like in this example by creating a new type, triggers a so-called schema recompilation. A message is displayed that blocks the screen and indicates that the schema is being compiled. Under the hood, the definition graph of the data model is modified, source code is generated from it and validated against the existing schema. When the compilation process is finished, the updated schema definition is available in all parts of the entire application without delay and any further deployment steps.

Deployment Format

folder / filedescription
componentsContains the shared components of the pages editor of Structr.
filesContains all files out of Sturctr’s virtual filesystem. Folders and files in the virtual filesystem are not being exported by default. If you want to include a folder or file into the export you have to set the flag includeInFrontendExport on each file or folder. Each file or folder will inherit this flag from its parent folder.
mail-templatesContains the mail-templates.
modulesContains the application configuration and definition of additional modules of Structr e.g. the flow engine.
pagesContains the created pages in the pages editor of Structr.
schemaContains the schema definition and code entered in the schema and code section of the Structr UI.
securityContains the resource access grants defined in the security section of the Structr UI.
templatesContains all template elements of the pages editor of Structr.
application-configuration-data.jsonContains the configured schema layouts of Structr’s schema editor.
components.jsonContains the settings e.g. visiblity flags, contentType or uuid for each file in the components folder of the export.
deploy.confContains information about the Structr system that created the export of the application.
files.jsonContains the settings e.g. visiblity flags, contentType or uuid for each file in the files folder of the export.
localizations.jsonContains the localizations that where created in the localizations section of the Structr UI and that can be used in server side scripting with the localize() function of Structr.
mail-templates.jsonContains the settings e.g. visiblity flags, locale or uuid for each file in the mail-templates folder of the export.
pages.jsonContains the settings e.g. visiblity flags, contentType or uuid for each file in the pages folder of the export.
pre-deploy.confScript that is run before deployment import. Use this to create users who are granted access to nodes in the export files.
post-deploy.confScript that is run after deployment import. Can be used to start any tasks which are necessary after import.
sites.jsonContains sites that are configured in the pages section of the Structr UI.
templates.jsonContains the settings e.g. visiblity flags, contentType or uuid for each file in the templates folder of the export.
widget.jsonContains the widgets that were created in the pages section of the Structr UI.

Simple Data Model

Currently our overview page contains a static table that was handcrafted by us. To populate the page, and in particular the table, with data from our database, we need a data model (also called schema) which describes the type and structure of the information we handle in our application. To do this, we head over to the Schema area by clicking on (Schema tab) in the main menu.

Graph-based permission resolution

In the above example, the schema is configured in such a way that users with the maintains relationship to a ProductGroup will have access to any Product object in the group they maintain, but not to the subgroups of the given group.

Schema relationships that are configured to allow domain permission resolution are called active relationships. Active relationships are displayed in a different color than normal relationships in the schema editor.

When a non-admin user accesses a private object (e.g. a Product node from the above example schema), Structr tries to find a path which ADDs the requested right or KEEPs the requested right from a node the user has the specific right on.

In detail: We assume that a user who has a read permission grant to a ProductGroup tries to access a Product contained in that group (for which the user does not have direct rights).
Structr will then traverse the active relationship(s) until a path is found which ADDs or KEEPs the requested right.

Successful path evaluation:

  • The (ProductGroup)-[:contains]->(Product) relationship is configured to keep read and write
  • The effective permissions at the end of the evaluation process are read and write

Unsuccessful path evaluation:

  • If a user who has a read permission grant to a product that is not contained in the product group he has access to, but in a subgroup of the given group, Structr will not be able to find a connected path of active relationships and will fail the permission resolution.
  • The user does not have any permission grants set on any node or only visibility flags are set on the data nodes.

Resource Access Grants

This part of Structr’s backend UI is the place where the entry points of Structr’s HTTP REST Service can be configured.

While the security system of Structr is focused on users and their security context (i.e. does the user has access to a given database entity?), the checking of resource access grants is focused on the URL path (the resource) of an HTTP request.

More precisely, if a user requests all entities of a given schema type via Structr’s REST interface with a call to the URL /structr/rest/SchemaType, Structr will check if the user is logged into the system and if a GET request on the resource /SchemaType is permitted for authenticated users. If the user is not logged into the system the GET permission for non-authenticated users has to be set for that resource.

Only when the permission for the resource is set, Structr will then check if user has grants for the actual database content and the entities of the type SchemaType.

The first message comes in case that the resource access grant with the signature SchemaType exists, but the method GET is not configured to be allowed for public users.
The second message comes in case a resource is requested for which no resource access grant exists at all (in this case a GET request for the view “public” on the type “SchemaType”).

For the first two lines in the above case (< v.4.0) two separate Resource Access Grants would need to be created. One with the signature SchemaType and the GET permission for public users. The other one with the signature SchemaType/_Public.

Schema

application.schema.automigration Allows Structr to attempt an automatic migration of the schema between different Structr versions.
application.schema.allowunknownkeys Allows access to properties that are not specified in the schema via get/set-Operations.

Menu Bar

The Schema Size Slider (Schema Size Slider) allows zooming the schema canvas to fit more elements on screen.

Simple Data Model

We now create a new datatype Project by typing “Project” into the “New type” field (New type) and hitting the “Add” button (Add). When done, it takes a couple of seconds for the schema to update.

Global Schema Methods

The section Global Schema Methods lists all available Global Schema Methods and provides access to admin users to run these methods. Possible use cases for such Global Schema methods are maintenance methods which add access grants to a given set of database entities, methods to start import routines or methods to migrate existing data to a new data model.

On the left-hand side of the tool there is an overview of available types defined in the Schema section of the Structr-Ui. Structr itself provides a large collection of pre-defined schema types like User or File, the list will only show a subset of those pre-defined schema types and all custom created ones by default. The filter can be adjusted by clicking on the wrench-symbol and selecting and deselecting the desired Filter.

Existing data in Neo4j

Data in a Neo4j database is available in Structr if the following requirements are met:

  1. For all data types in Neo4j that should be accessed through Structr, data types must exist in Structr that match the node label. Create these types in the Schema Editor.
  2. The type attribute of every node instance is set to the primary type (=simple class name). This is necessary because Neo4j labels don’t have a reliable order.
  3. Nodes and relationships have an id String property with a UUID as value. Use the “Add UUIDs” function from Schema section -> Admin -> Indexing.
  4. The primary type (simple class name) as well as the supertypes and implementing interfaces have to be set as labels in Neo4j. Use the maintenance commandCreate Labels” from Schema -> Admin -> Indexing to set all necessary labels.

Resource Access Grants

If a user requests all entities of a given schema type via Structr’s REST interface with a call to the URL /structr/rest/SchemaType, Structr will check if the user is logged into the system and if a GET request on the resource SchemaType is permitted for authenticated users. If the user is not logged into the system the permission for non-authenticated users has to be set for that resource.

snapshot

Creates a schema snapshot and writes it to a local file on the server the Structr instance is running on. This maintenance command is used internally in the Schema section to manage schema snapshots.

Logging

nodeextender.log Enables the logging of generated Java code of the dynamic schema entities to the logfile. This setting allows you to investigate and debug the generation of Java code for your schema entities in cases where something goes wrong.
nodeextender.log.errors Enables the logging of Java compilation errors when compiling the dynamic schema of your application.
log.requests Enables full request logging for all requests handled by Structr. Caution, the log file can get very large when a lot of requests with lots of content are made.
log.debug Controls the debug() built-in function, which will behave exactly like the log() function if enabled.
log.functions.stacktrace Enables stacktrace logging for script calls and built-in functions. If enabled, a scripting error will write the full Java stack trace to the logfile.
log.prefix Sets the prefix for the request log file that is written when log.requests is enabled.
log.javascript.exception.request Adds path, queryString and parameterMap to JavaScript exceptions (if available) if enabled.
log.directorywatchservice.scanquietly Prevents logging of each scan process for every folder processed by the directory watch service.

Layouts

To help you focus on different aspects of you schema (i.e. different subgraphs of you application) Structr provides so-called schema layouts. The layouts can be managed, via the layouts tab in the Schema Tools. They can be applied via the Apply Layout button (Apply Layout) as shown below.