RFC: Composites should be specified on the composite property itself

[mikestopcontinues]

If I understand correctly, the current method of specifying composite keys occurs with array attribute values. I saw this cause an issue in #32. I believe the solution is to migrate the api to something that looks like this:

Entity({
  attributes: {
    pk: {composite: ['STATIC_WORD', {attr: '_et'}, {attr: 'id'}], delimiter: '#'},
    id: {default: () => nanoid()},
  },
})

This would allow specifying multiple composites, and it would retain the space-saving features of the current implementation. Additionally, I think it's easier to parse. Does this break anything I'm not aware of?

[jeremydaly]

Hi @mikestopcontinues! Thanks for this suggestion. I've never been happy with the current way that composites work, and this is an interesting idea. I have a few other methods I was playing around with, so expect to see something soon.

[mikestopcontinues]

Awesome! I'm looking forward to it!

[darbio]

I think this could be a valid solution for #105.

[naorpeled]

Hey @mikestopcontinues, thanks for opening this issue and sorry for the delay.

The composite key properties functionality will be deprecated soon, therefore we encourage using the default property option instead. Here is an example.

Feel free to ping me if you have any questions/need anything 😎