Do not assume that the primary key is "id"

[aesmail]

Need a way to figure out the primary key.
Might also need to check if the primary key is a set of fields and not just a single field.

[wstucco]

You can retrieve the primary key of a Module schema using

Module.__schema__(:primary_key)

https://hexdocs.pm/ecto/Ecto.Schema.html#module-reflection

[aesmail]

Hello @wstucco
You're right, but this potentially could return a list of fields (composite primary keys). In this case, too much of kaffy's internals must change in order to support this. I'm not sure if this is actually worth supporting in the time being.

First step is to support single-field custom primary keys. Later, I'll see if supporting composite primary keys is feasible or not.

[cultofmetatron]

+1 this, would be great for those of us incorporating phoenix on top of legacy databases

[nullpilot]

Hi @aesmail ! I have have been using Kaffy for a small project that has some joiner tables, where I left off the id and used a composite primary key instead. As Kaffy doesn't currently support either, I thought it was a good opportunity to look into it a bit and see if I could come up with a working solution. It's not done yet, but it's at a point where basic navigation and modification seem fine, and it would be great to get some feedback, to see if it's worth moving forward with.

The approach used is to introduce serialize_id/2 and deserialize_id/2 in the admin module, which by default just join/split all primary key values with a ".", which is then used for the routes and some form values. This way the routing logic doesn't have to change at all, and generally there should be no visible changes for schemas that worked previously.

The major places where a hard coded :id was assumed have been rewritten to use the primary key list returned by the schema and the new (de)serialized id's to match.

Would love to hear your thoughts on this.

[aesmail]

Hey @nullpilot,
Thanks a lot for taking the time to give this issue a shot. I like the idea you're proposing and I'm glad you're sharing the initial work because Kaffy is moving to a new direction with the next release. I'll try to use your solution with what I have locally and provide feedback in a few days. Also, since I'm not sharing a lot about what's coming next, and this might make it harder for people to contribute effectively, I'll open an new issue that will explain what the major change in v0.10.0 is all about.

I'll keep your PR open for now, but I expect that it will be extremely valuable in the coming days.

[wstucco]

@nullpilot @aesmail

Can I suggest to not to use the dot as a separator?

In PostgreSQL, for example, this code is valid

CREATE TABLE test (
  "id.id" INT
);
INSERT INTO test ("id.id") VALUES (1);

I think using Json or Erlang ETF as serialization format would be better.

Something along the lines of

[<primary keys>]
|> :erlang.term_to_binary()
|> Base.encode64()

or

Jason.encode([<primary keys>])

[nullpilot]

@aesmail: Thanks for checking it out, glad to hear it might be helpful. I'll keep an eye on the repo for what you have coming up.

@wstucco: The serialization as is only joins together the values, not the names of the keys, so in the case of uint/serial/uuid there shouldn't be a problem. In the case of strings or some other type that could introduce ambiguity, the methods could be overwritten to use one of the methods you suggest with a final Base.url_encode64/2.

In my local example the route currently ends up looking something like this for a binary-id composite:

http://localhost:4000/admin/listings/product_tags/bcb391ff-8ce6-47e5-8d1d-068173361f57.eeed2940-644a-4b0d-ae40-919dc670a7a0

[wstucco]

@nullpilot

The serialization as is only joins together the values

Sorry, my fault, I was only trying to show that the dot can appear in many places one wouldn't think to find them.

I think safer defaults will avoid weird bugs in the future.

In the case of composite keys there's a very high chance they won't be of a safe base type.

The problem is that if the keys have unsafe values the serializer will produce the wrong result, but the deserializer won't fail, it will simply emit the wrong key values.

(1)> Enum.join([1.2, 3.4], ".")
"1.2.3.4"

(2)> String.split("1.2.3.4", ".") |> Enum.zip(["id", "sub_id"])
[{"1", "id"}, {"2", "sub_id"}]

while ETF returns the correct result

(3)> :erlang.term_to_binary([1.2, 3.4]) 
     |> Base.encode64() 
     |> Base.decode64!() 
     |> :erlang.binary_to_term() 
     |> Enum.zip(["id", "sub_id"])
[{1.2, "id"}, {3.4, "sub_id"}]

[nullpilot]

That's a good point, I like the solution as well. I do think there is some value in "readable" URLs that contain the actual IDs where possible (maybe even non-primary, unique slugs in the future, for example) - but having a more encompassing default is absolutely worth the consideration. Since the setup is quite flexible, it could even be combined to use a "best effort" approach, depending on the types of primary keys present in a schema.