API Enhancement Request

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • API Enhancement Request

    I would like to have additional API functions in the PALO server.

    This would both make the development of clients much easier (90% less code necessary) and lower the barriers for usage.
    It would also reduce the latency (e.g. 75%) and improve performance a lot.

    I would like an API like
    localhost:7777/cell/replace?si…&cube=DemoCube&namedpath="Vienna","2014","Light bulbs","Sales"&value=123.00&splash=1
    in addition to the current API that only supports IDs instead of names:
    The new API would then automatically create new Elements for the given dimensions, where necessary. (Or give an error if you want to parameterize it)
    I would also like a corresponding bulk API.
  • Ah, now I have it working. Yes, name_path is there and works.
    There is just one limitation: It does not automatically create the necessary elements when they do not exist yet.
    It can only change the value of cells of existing elements, and I get an error if the element does not exist.
    Is there another undocumented parameter to automatically create elements when needed?
  • I am currently trying to write data into Palo from a Perl based application.
    I previously worked on a PHP based project, where the PHP library cared about the element creation, now I am trying to do it on my own with the HTTP based API.

    If the Palo server does the element creation, it is done in one place, and all the clients can use it. If the server does not do the element creation, all clients have to implement it, which makes the whole system more costly, and the barrier to entry for other languages and environments higher.

    I think it would also make it much easier to create libraries for
    other languages and environments, so that more applications and systems
    can use Palo directly, and write and store their data in realtime.

    I think the missing demand comes from the fact that the Palo server is currently not marketed to be a directly usable OLAP database engine for applications.

    I also see a problem for environments with high network latency, there the additional round-trips to create several elements can easily cost a lot of performance. HTTP/1.1 and connection pooling can likely mitigate that problem, but this would also cost a lot of complexity on the client side.

    By the way, is there also a name_database and name_cube parameter? It would be nice too, but it´s ok without them as well.

    And please add the documentation for the name_path parameter.

    Thanks a lot for your help!
  • Yes. I agree with your arguments.
    I added it to task list for next major version, we'll have to first prioritize the feature.
    Yes there are also other name_* version of parameters. But because they are not documented they are not official. You can use them on your risk now.
    Last week we already created tasks to document and support these parameters. So I suppose it could be public in 5.1sr2 and 6.0 or what will be the next major version.