Wednesday, April 11, 2018

Tutorial: Resize an image and save it to a posting on AmiDb

The ability to resize and add images to postings is ground 0 feature for most apps and websites.

In this example, I will use AmiDb and show you how easy it to resize an image, save it to a posting and view the results.

Note: This example can be done entirely over JavaScript.

Step 1) Let us first create a model representing a posting.

POST URL: https://www.amidb.com/lgc/service/model/save/posting

Payload JSON:
    {
    "pscope": "O",
    "fields":
    {
        "ska":
        {
            "name": "posting_id",
            "type": "integer"
        },  
        "cola":
        {
            "name": "title"
        }
    },
    "storage":
    {
        "engine": "Cassandra"
    }  
}

Response:
{
  "n": "3n",
  "success": true,
  "modelname": "posting",
  "result": {
    "size": 1,
    "entry": [
      {
        "pscope": "O",
        "_metasysggmdl": {
          "_ak": "299f786a830c9a8bb4624d2159a4d344"
        },
        "storage": {
          "engine": "Cassandra"
        },
        "fields": {
          "ska": {
            "name": "posting_id",
            "type": "integer"
          },
          "cola": {
            "name": "title"
          }
        }
      }
    ]
  },
  "http_status": 200
}

 
Step 2) Upload an image from your phone or browser to the Resize API.
 
MultiPart POST URL: https://www.amidb.com/lgc/service/image/convert/png
 
Request Payload: 
Form-Data: Name:"convertopts", Value:"-resize 100x100"
File-Data: The image file 

Response:
{
  "n":"3n",
  "success":true,
  "result":{
     "size":1,
     "entry":[
      {"_metasysfilestage":
        {
         "_ak":"5e633c9ff2b0f8085cccad9d8cf8f1f2"
        },
        "stagekey":"5e633c9ff2b0f8085cccad9d8cf8f1f2",
        "_exts":1523442481023,
        "fstageid":8476561119032
      }
     ]
   },
   "http_status":200
}


Step 3) Create your posting and attach the stagekey to it.
 
POST URL: https://www.amidb.com/lgc/service/mcot/save/posting

Payload JSON:
Here we attach the stagekey to position0, variant0 (_perupv00).
 {
    "data":[
        {
            "posting_id":"1",
            "title":"My first posting with an image",
            "_perupv00":"5e633c9ff2b0f8085cccad9d8cf8f1f2",
            "_peruname0":"img.png"
        }
    ]
 }

Response:
{
  "n": "3n",
  "success": true,
  "result": {
    "size": 1,
    "entry": [
      {
        "posting_id": 1,
        "title": "My first posting with an image",
        "_metaposting": {
          "_ak": "5b1b3f67777235c3242923dc1ef23006"
        },
        "_peruname0": "img.png"
      }
    ]
  },
  "http_status": 200
} 
 
--------------------- 
SUMMARY:
With a few steps I have demonstrated how you can upload an image, 
resize it and attach it to your first posting. The attachment key of 
the posted row can be used to view the posting itself and its images.
 
To view the posting:
GET: https://www.amidb.com/lgc/service/mcot/get/posting/5b1b3f67777235c3242923dc1ef23006 

To view the image: 
GET: https://www.amidb.com/lgc/service/file/download/posting/5b1b3f67777235c3242923dc1ef23006/_perupv00
Here you refer the image's name by the standard naming 
convention _perupv00 (position0, variant0)

---------------------
Thank you for reading and hope you will try it out for yourself!

Friday, March 30, 2018

How does AmiDb partition data for cassandra and elasticsearch?

I have created a model but I'm not sure how it stores data into cassandra or elasticsearch
My model (changed the field names for privacy) has ska (id="employeeid"), cola (firstname), colb (lastname)
Can you explain how the data is stored in cassandra or elasticsearch?
Answer
AmiDb creates partitions in cassandra based on the headers that you generate and the model name being used.
Hence data is always partitioned by the pscope (owner,[container,[tenant]])+modelname
So when you design your model keep this in mind to achieve horizontal scalability.
These partitions go to the keyspace the model is defined in, and models can share a keyspace.
AmiDb already creates keyspaces for you based on usage type, for example caches go to a separate keyspace, user information goes to another keyspace.
All the user data goes to one keyspace. In production we believe you may not need to create additional keyspaces, but if you desire so you can log into the management console and create this. (Not visible on free cluster)
For elastic search, since partitions==indexes and there is no keyspace, we can end up into too many idexes and open file limits if we were to do the same. Hence, amidb internally  collapses indexes into one and allows you to split or merge indexes based on usage pattern. One story under development is to automate this behind the scenes. For now you have management consoles to do this task. (Not visible on free cluster).
Your queries are always at the model level and hence they do not depend on keyspace or indexname changes.