Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 17:33
    codecov[bot] commented #1542
  • 17:33
    codecov[bot] commented #1542
  • 17:31
    codecov[bot] commented #1542
  • 17:31
    codecov[bot] commented #1542
  • 17:11
    kuzzle commented #1542
  • 17:11
    kuzzle commented #1542
  • 17:09
    codecov[bot] commented #1542
  • 17:09
    codecov[bot] commented #1542
  • 17:09
    Aschen synchronize #1542
  • 17:09

    Aschen on 1541-support-script-fields-query

    Sonarqube (compare)

  • 16:53
    codecov[bot] commented #1542
  • 16:53
    codecov[bot] commented #1542
  • 16:31
    kuzzle commented #1542
  • 16:30
    Aschen commented #1541
  • 16:29
    Aschen labeled #1542
  • 16:29
    Aschen assigned #1542
  • 16:29
    Aschen labeled #1542
  • 16:29
    Aschen opened #1542
  • 16:24

    Aschen on 1541-support-script-fields-query

    Support script_fields query (compare)

  • 16:07
    codecov[bot] commented #1535
Adrien Maret
@Aschen
I don't understand how a client can use a different mappings, mappings are defined for each collection on the backend
Yes, you could save this history in the _meta field.
And there is no way to remove a field from a collection. It's due to Elasticsearch and Lucene limitations :/
Gabriel Pulido
@gpulido
arg
Adrien Maret
@Aschen
The only way to really remove a field is to remove and recreate the collection
But if you didn't need a field anymore, you can just stop using it
Gabriel Pulido
@gpulido
Interesting, doesn't hit the performance?
Adrien Maret
@Aschen
No, since Elasticsearch is a document oriented database, if you didn't use a field, it does not take disk space, memory usage or whatever
If you want to be sure that your users will not use this field in the futur, you can setup a custom validator: https://docs.kuzzle.io/core/2/guides/essentials/data-validation/#advanced-validation
These validator use Koncorde syntax (the same as for realtime filters), so you can specify a filter that ensure that a field does not exist in the document before saving it
Gabriel Pulido
@gpulido
good to know. It is my first real use of a non sql db after years of doing "normalized dbs ;) )" and coming from a maths background it is something I have to diggest :)
Adrien Maret
@Aschen
Ahah no problems :-) I know that document oriented db can be confusing. And Elasticsearch is also a search index using Lucene so there is even more differences
Gabriel Pulido
@gpulido
also I already have a very extensive OO model with lots of child collections that I would need to "rethink" on the angular app.
about 30 classes
Also, I'm adding to my kuzzle ngrx data service extension a way to create the collection for the entity on the db
entity-kuzzle mapping
hence the migration questions :)
Adrien Maret
@Aschen
Ok I see :-)
Adrien Maret
@Aschen

@/all
After several months of development, we are very proud to announce the official release of Kuzzle v2!
Among many changes, this new version includes support for Elasticsearch 7.4.0 and Node.js 12.
You can see the complete list of new features in the release on Github: https://github.com/kuzzleio/kuzzle/releases/tag/2.0.0
In accordance with our LTS policy, the latest Kuzzle version 1.11.0 will be supported during 18 months until April 2021.
We recommend that you migrate to Kuzzle v2 in order to have access to our latest features!
To facilitate your migration to Kuzzle v2, you can use this change guide and the automated migration scripts that we have developed:
https://docs.kuzzle.io/core/2/guides/upgrade-kuzzle/changes/
https://docs.kuzzle.io/core/2/guides/upgrade-kuzzle/upgrade/

For more information, please visit our blog: https://blog.kuzzle.io/kuzzle-2.0-released

Gabriel Pulido
@gpulido
congratulations!
Gabriel Pulido
@gpulido
@Aschen I noticed that the s3 pluggin documentation is not updated. It is still defining the "region" for example.
Gabriel Pulido
@gpulido
another question. I know that Elasticsearch doesn't support uniqueid fields besides the id. Is there any other way to enforce a field to be unique?
Adrien Maret
@Aschen
I just started the release process: kuzzleio/kuzzle-plugin-s3#9
And no, there is no way to ensure unicity for a field. The only way is to make a count request first to see if the field already exists.
Gabriel Pulido
@gpulido
Thanks that is what I thought. As always with this kind of "problem" (ensure unique values on a field) the hard part is where to place the check for "be unique". If you place it on the client, to make the operation atomic is hard, even more if we allow offline creation of elements. So the right place should be on the server. I have read a way with ES that is to have another collection with two fields: the "id" that would represent the value that we want to be single value, and another field with the id of the original document, and use the fact that the id can be manually provided by the user and it will be checked by ES
So to create a new element on the original collection is a two steps-workflow: 1) create a document on the "unique table", and if it is allowed and returned, create the original element with the id
Hum I'm thinking that you only need the "index" table to have the id. As it is only used to keep the already used values
Hmm yes it could be a workaround
And you could implement this logic with pipe on document:beforeCreate and document:beforeCreateOrReplace events
Why do you need to ensure unicity on a particular field?
Gabriel Pulido
@gpulido
I'm create content that could be accessed through an url
I have a list of tournaments
and each tornament has a detail view on the client
like: tournaments/id
the problem is that if the user wants to access directly to the url of one tournament he needs to remember a UUID at this moment
one solution is to give the tournament a more user-friendly unique name
so it can access tournaments/my-unique-name
However for the moment I'm good with the id, I just came to it and wonder if kuzzle allowed unique values on the mapping, so I reach to the ES docs and then I asked
:)
Gabriel Pulido
@gpulido
I'm very green at this moment wit kuzzle / ES so I'm learning in "espiral" and pipes are at this moment out of my "knowledge" reach. Also I would like to review the S3 plugin in a future to try to abstract the storage layer (as I already explained on the plugin github issue)
but it will be when I feel more confident with the entire stack. Too many mobile parts at this moment for me :()
:)
Adrien Maret
@Aschen

Each request generate events, particularly on api methods two event are generated:

  • one before Kuzzle process the request
  • one after Kuzzle has processed the request
    Pipes are just method that you could plug on these events.

For example you can plug a pipe before document creation (document:beforeCreate event), the pipe method is called with the Request object that contain all the input (document id, document body, etc).
In this method you could do a search query on your collection to ensure there is no other document with the same friendly name, and if there is one, you can throw an error from the pipe and Kuzzle will then stop the request processing and return the error message to the user

Gabriel Pulido
@gpulido
Ok looks powerfull. The pipes are only available for pluggins?
Adrien Maret
@Aschen
Yes, it's part of the plugin system
Gabriel Pulido
@gpulido
Ok, I will take a look and I'll add to the queue to create a kuzzle plugin to handle such cases
Gabriel Pulido
@gpulido
Hello again, I'm having problems trying to build for production the angular app that includes the kuzzle-sdk
Gabriel Pulido
@gpulido
I'm filling an issue