Expected behavior

Use windows path with backslash.

Actual behavior

Some path use linux-style slash

• Materia Version: pre-release

Expected behavior

The following query config should works without addition "opts.values" field:

{
    "id": "companiesSince",
    "type": "sql",
    "params": [
        {
            "name": "date",
            "type": "date",
            "required": true
        }
    ],
    "opts": {
        "query": "SELECT speaker.company\nFROM speaker, event\nWHERE event.date_start >= :date\n    AND event.slug = speaker.slug_event\nGROUP BY speaker.company"
    }
}

Actual behavior

This query config is working

{
    "id": "companiesSince",
    "type": "sql",
    "params": [
        {
            "name": "date",
            "type": "date",
            "required": true
        }
    ],
    "opts": {
        "values": {
            "date": "="
        },
        "query": "SELECT speaker.company\nFROM speaker, event\nWHERE event.date_start >= :date\n    AND event.slug = speaker.slug_event\nGROUP BY speaker.company"
    }
}

but without opts.values (as in the expected behavior), it throws:

Error: Named parameter ":date" has no value in the given object.

• Materia Version: pre-release

If we integrate @materia/users in this repository and install it by default in every applications, we can use admin role to connect materia-server admin API instead of using rootPassword.

Advantage:

• no rootPassword written in clear text in materia.json & materia.prod.json
• Same login system than the one used in the application (not duplicated in 2 different system)

If no database setup, we can still connect to a local sqlite database to have the minimal user structure

If no admin user defined, need a cli command to initialize the first admin user (to let materia-designer connect the admin API)

• Materia Version: v1.0.0-beta.1

Expected behavior

when creating the CustomQuery object with opts.query which contain the code. It should write the code in the file opts.file.

Actual behavior

The custom query can load the Javascript file and execute it. When saving the query, it return the JSON with the filename in opts.file but there is no way to store the query or retrieve the code of the query.

• Materia Version: pre-release

Expected behavior

This should alter the table to add/remove the primary key in db, to match the entity.

Actual behavior

Does not change the primary key(s)

Step to reproduce the behavior

Update a field to add or remove a primary key, and check in db that did not changed the pk, or launch a synchronization and watch the diff.

• Materia Version: pre-release

Expected behavior

launch the server with the command line materia start

Actual behavior

Error in the console when running materia start:

command not found
/usr/local/bin/materia: line 3: syntax error near unexpected token `('
/usr/local/bin/materia: line 3: `let argv = require('minimist')(process.argv.slice(2))'

Actually the server can be run with forever start ./node_modules/materia-server/cli/index.js start

Step to reproduce the behavior

• sudo npm install -g materia-server
• materia start

• Materia Version: v0.1.1

Expected behavior

An endpoint is linked to a list of query. In this list, only one query can be a findAll or a findOne query. When the endpoint is called, every query are executed in parallel.

Actual behavior

An endpoint is linked to a single query.

• Materia Version: pre-release

Expected behavior

$> materia addons install {addon-name|addon-url}[#{version}]
Install an addon by its name or url to the latest version or to the specified version if it is specified

$> materia addons update {addon-name|addon-url}[#{version}]
Update an addon by its name or url to the latest version or to the specified version if it is specified

$> materia addons remove {addon-name|addon-url}
Remove an addon by its name or url

$> materia addons search {query}
Search an addon

The feature would be developed in /lib to be used programmatically from Materia designer and from the CLI.
All addons would be installed first in the Materia directory, then a symbolic link is created to the current app. Then, if another app is using the same addon, just a symbolic link is needed.

• Materia Version: pre-release

What is the OSS license for this project?

• Materia Version: v0.1.1

Expected behavior

Do not have a field default stored in entities and use only defaultValue, and replace default field by a hasDefault method

Actual behavior

Rely on default boolean

Step to reproduce the behavior

Create an entity

• Materia Version: pre-release

It looks like that a query in a transaction (sequelize.query) that is failing neither resolves its promise nor rollbacks the transaction. Only on travis.

The tests are passing on the same environment (same node / npm / linux ... versions). This needs some deeper tests and comparisons.

• Materia Version: v0.5

Currently, we have 2 server profile: dev and prod defined respectively in materia.json and materia.prod.json

We could handle more server profile by detecting materia.json + materia.*.json files
Each files materia.*.json is a new server profile where * is the profile name

In Materia Designer, we could connect in live mode to any server profile (e.g. prod / staging / prod2 etc...).

• Materia Version: v1.0.0-beta.1

Expected behavior

If GET method:
All params from the query goes as endpoint params

If POST method:
All params from the query goes as endpoint data

If PUT method:
All params from the query goes as endpoint data

If DELETE method:
All params from the query goes as endpoint params

If there is params in the URL (e.g. /customers/:id), they are pushed as endpoint params

The actual behavior is still needed when the query is a custom Javascript function

Actual behavior

For the moment, endpoints declare their params and data while the query associated also declare its params

• Materia Version: pre-release

Expected behavior

When updating a field type from text to integer (or boolean, date...), this should cast the data to the new type (c.f. http://stackoverflow.com/questions/13170570/change-type-of-varchar-field-to-integer-cannot-be-cast-automatically-to-type-i)

Actual behavior

The SQL request looks like ALTER TABLE "..." ALTER COLUMN "..." TYPE TEXT

Step to reproduce the behavior

Changing a field type from type text to number, date or boolean throws an error when it should cast the data to the new type:

column "..." cannot be cast automatically to type ...

• Materia Version: pre-release

Related with https://github.com/thyb/materia-designer/issues/11 and https://github.com/thyb/materia-designer/issues/12

• Materia Version: pre-release

Expected behavior

$> materia deploy {provider} [--{param}={value}]*

Deploy an app directly from the CLI. The feature would be developed in /lib to be used programmatically from Materia designer and from the CLI

• Materia Version: pre-release

It would be easier to write models and custom queries if they were in the same file (hopefully Typescript).

This is an example of what I mean by merging queries and models in a single file:

@Entity('user')
class UserModel {
    @Field({type: DataType.NUMBER, primary: true, autoIncrement: true}) id;
    @Field({type: DataType.TEXT, required: true}) email;
    @Field({type: DataType.TEXT, required: true}) password;
    @Field({type: DataType.BOOLEAN}) public_email = false

    constructor(private app: App) {}

    @CustomQuery({
        params: [{
            name: 'email',
            type: DataType.TEXT
            required: true
        },{
            name: 'password',
            type: DataType.TEXT
            required: true
        }]
    })
    signin(params) {
        // todo
    }
}

Many requirements are needed to implement this new syntax:

• Handle Typescript files in server/ folder (compilation in watch mode in Materia Designer)
• Need to be able to edit the class programmatically without breaking existing code
• Need to be able to read the class as we were reading the json file (reflexion / introspection of the class).

• Materia Version: v1.0.0-beta.1

When an application begin to have lots of endpoints, api.json can be long and hard to read.

As #31, endpoints would be probably easier to read/write if api.json + controllers were merged

Something like the following example could work if as #31 we are able to edit / read the information contained in the class

@Controller('user')
class UserController {
  constructor(private app: App) {}

  @Get('/user/:email')
  getUser = {
     entity: 'user',
     query: 'getByEmail'
  }

  @Post({
    endpoint: '/user/signin',
    params: [{
      name: 'email',
      type: DataType.TEXT,
      required: true
    },{
      name: 'password',
      type: DataType.TEXT,
      required: true
    }]
  })
  signin(req, res) {
      //todo
      res.status(200).send('ok')
  }
}

• Materia Version: v1.0.0-beta.1

Expected behavior

No warning

Actual behavior

(node:97572)   DeprecationWarning: Using Buffer without `new` will soon stop working. Use `new Buffer()`, or preferably `Buffer.from()`, `Buffer.allocUnsafe()` or `Buffer.alloc()` instead.
  
  - connection.js:299 Object.<anonymous>
    [materia-server]/[pg]/lib/connection.js:299:19
  
  - module.js:20 require
    internal/module.js:20:19
  
  - client.js:18 Object.<anonymous>
    [materia-server]/[pg]/lib/client.js:18:18

Step to reproduce the behavior

with node v7.0.0:

materia start in any app

It's related to brianc/node-postgres#1163

• Materia Version: v0.3.2

Expected behavior

Materia Server should handle optional database.

If database.json is missing, it should:

• Print a warning message in the console
• Don't load Entities and Queries
• Don't load Endpoints that rely on a query

--no-db option in the CLI should be available to remove the warning (and skip the verification of database.json etc.)

Actual behavior

It crash silently and the process is terminated

~/materia-apps/MateriaWebMap> materia start 
Starting materia in /Users/thyb/materia-apps/MateriaWebMap
~/materia-apps/MateriaWebMap>

Step to reproduce the behavior

• in the application directory: mv database.json database.json.bak
• then run materia start

• Materia Version: v0.1.1

Expected behavior

• app.api.permissions.findAll() should list all permissions added by name

• app.api.permissions.add(permissionName, middlewareFunction) should add a permission by its name

• app.api.permissions.remove(permissionName) should remove a permission by its name

• middlewareFunction should have this prototype:

  function(req, res, next) {
       //todo
  }
  

Actual behavior

• Not able to list permission

• app.api.permissions.addFilter(middlewareFunction) without setting up a name

• Not able to remove a permission

• Currently, the middlewareFunction have this prototype:

  function(permissions, req, res) {
      //TODO
  }
  

It allows the same permissions features but it adds the possibility to list and remove existing permission (e.g. if an addon is removed, it is expected to remove the associated permissions)

The API changes are also more similar to other Materia Object (e.g. app.endpoints.findAll() etc...)

• Materia Version: pre-release

Addons like Mailjet or Stripe generate lots of Virtual Entities and it can be hard to visualize everything easily when combined with the entities made by the users.

As a simple workaround, we can add filters in Entities Structure view in Materia Designer to hide unwanted entities

A better solution would be to be able to create Folder which contains Entity

e.g. add a folder key in the model file to display this entity in a folder

{
   ...
   folder: 'Stripe'
}

• Materia Version: v0.1.1

Expected behavior

app.addons.findAll() -> get the list of installed addons with the associated metadata: name, description, logo, author
These metadata are in the package.json file in the addon directory.

Actual behavior

app.addons.findAll() doesn't exist.
app.addons.addons is an array containing installed addons without the metadata (we can't even know the name of the addon without checking the class name)

• Materia Version: pre-release

Expected behavior

Separate endpoint.getAllParams() and endpoint.getAllData()

A method endpoint.getMergedParams() could still exists with the actual behavior

Actual behavior

endpoint.getAllParams() send a merge of params and data.

• Materia Version: pre-release

Expected behavior

Support Field type Image and File which represent image and file upload via the API.

Behind the scene, the SQL column is a TEXT containing the link/path of an image or a file.
A file upload input needs to be displayed as query/endpoint params (for create/update queries)
Endpoints need to handle file upload correctly.
Some options can be added when creating/updating a field of this type:

• The directory of the file
• Resize/crop for image

Validators associated with these new type:

• MaxSizeValidator
• MinSizeValidator
• FileExtensionValidator

• Materia Version: pre-release

Expected behavior

Define an index name to group unicity on more fields. e.g.

uniqueOne: { type: Sequelize.STRING,  unique: 'compositeIndex'},
uniqueTwo: { type: Sequelize.INTEGER, unique: 'compositeIndex'}

Actual behavior

the unique property accepts only a boolean

• Materia Version: pre-release

The automatic migration may sometimes break. When updating entities, we should generate a migration file that can be applied when deploying the application.

We can use this to generate migrations step:
http://docs.sequelizejs.com/manual/tutorial/migrations.html

Migrations should be displayed in Materia designer and should be editable easily.

The migrations could be automatically applied at deployments time to get the same behavior than what we currently have with automatic migration but it would add some control on how the migration is done.

• Materia Version: v1.0.0-beta.1

Expected behavior

Ignore auto increment flag when creating / updating a field that is not a number

Actual behavior

Try to add serial in DB

Step to reproduce the behavior

On designer, change a field type number which has auto increment to type text (without uncheck it before)

• Materia Version: pre-release

Expected behavior

An entity should have an id (unique). So when an entity or a field is rename, as the id doesn't change, materia can know it's just a rename and apply this change in the database without data loss.

Actual behavior

An entity is currently identified by its name. The issue is when a user update a json file to rename an entity or a field, materia synchronize the database with the json file and don't see that it's a rename. Instead, it will delete the entity and create a new entity with the new name.

This is dangerous because data can be lost by removing an entire table.

Step to reproduce the behavior

• Create an entity
• Create a row of data
• Go edit the name of the entity directly in the json.
• Go back to check the data => the table is cleared

• Materia Version: pre-release