Support alternate primary keys / remove assumption of :id key on struct

[JohnnyCurran]

Describe the bug
If a schema does not have an :id key, it cannot be rendered with LiveAdmin due to the assumption on line 109 at

live_admin/lib/live_admin/components/resource/index.ex

Line 109 in c512842

data-record-id={record.id}

To Reproduce
Steps to reproduce the behavior:
0. Create a schema without an :id key

1. Go to LiveAdmin / try to list out the resource
2. See error

Expected behavior
Resource should show correctly

Screenshots
If applicable, add screenshots to help explain your problem.

Environment:

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Additional context
Conversation starts here https://elixirforum.com/t/liveadmin-phoenix-admin-ui-built-on-liveview/46421/33?u=johnnycurran

[tfwright]

Hi @JohnnyCurran thanks for bringing this to my attention. Can you share any more info about your schema? Are you using a different naming scheme for your primary keys?

[JohnnyCurran]

@tfwright The data comes from an external API and we use it basically as a cache so we aren't doing http calls to fetch it.

This is the only schema we have named this way. Table was created with primary_key: false:

create table(:business_redacted, primary_key: false)

and then the schema is decorated with:

@primary_key {:unitid, :integer, autogenerate: false}

For the time being, I've added:

field :id, :string, virtual: true

to our schema so that live_admin works

EDIT: Live_admin works for viewing, but not for editing with the addition of the virtual field. I'll keep digging to see if this is related to the :id issue

Edit 2: Looks like we have an {:array, :map} field on our struct which is incompatible with some of the input options. Unrelated to this issue and I hid it from the form editor and things are running smoothly again

[tfwright]

OK yeah I think LiveAdmin just needs to be made aware of primary keys with alternate names. Probably this should be doable without requiring additional config by reflecting on the schema struct, but I'll take a closer look at let you know.

[tfwright]

@JohnnyCurran if you want to try out the changes in #89 they should allow you to use your custom primary key without any additional config. Let me know if you run into any issues!

[JohnnyCurran]

@tfwright I can confirm this allowed me to use it without defining a virtual :id field.

To note: I did need to derive Phoenix.Param on the struct which is, of course not an issue with the lib, but would be a helpful addition to a section of the docs if there's a section on non-:id primary keys in the future

[tfwright]

@JohnnyCurran thanks for reminding me of the issue with Phoenix.Param I do think that might be something that LiveAdmin should address although you are right that generally one would expect library authors to already be doing that. But Phoenix/Ecto itself doesn't enforce use of to_param so it's possible they wouldn't otherwise need to, and there's no technical reason for LiveAdmin to rely on it, just a convenience, so I think I will take it out.