nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Replicant Order Column Question

sumitk

Hi,

The Datadeploy guide states the below statement,

When a replicant order column in a group is made a key column for the group, the group must contain a column that maps the path attribute value. Otherwise, real-updates are not supported.

Can you please me know which path attribute value is being referred? or how to use this feature when the column is a primary key column?

OD: 7.1
OS: Unix
TS: 7.2.1

Thanks,
Sumit

Find more posts tagged with

Comments

Rick Poulin

The path value is the path to the file being deployed. Because it's unique to the DCR, you can use it as a primary key in this way. The replicant order column wouldn't be sufficient for uniqueness.

From the DD Admin guide:

When OpenDeploy sees a column named Path it will insert the path of the file as the value of the column. Since file paths are always unique, a path value can serve as a primary key for a table.
[PHP]

[/PHP]

Not sure if the important thing is the 'name' or the 'value-from-field' attribute there, but you can test on your own.

sumitk

Thanks Rick for the response. I have one more question.
Do we have any problem while inserting data into same table through different groups in DD config.

For eg.

[PHP]

[/PHP]

The problem i am facing is, when there is no data for the specific DCR in the database, all replicant values get inserted as seperate rows into database. But when i re-run the deployment for the second time, the values from grp1 gets updated while values from grp2 gets deleted.

I am not able to understand as to why this is happening.
DD config file has been attached for reference.

Thanks,
Sumit

Rick Poulin

Do we have any problem while inserting data into same table through different groups in DD config.

Yes that's a problem. The way DD was designed is based on the assumption that one record/group combination is all there ever was and existed for that table and PK. That means that whatever group executes second will decide that the first information is no longer current and will delete it, replacing it from the info from the second group.

There's some crafty ways around this design, using either "fake" replicants or composite primary keys, but I'd recommend neither for a new implementation because there's a **** ton of gotchas with that approach. You'd best rethink your design instead.

sumitk

That means that whatever group executes second will decide that the first information is no longer current and will delete it, replacing it from the info from the second group.

Rick, I am getting the result otherway round. The grp1 which is the first group in DD config gets considered and data is updated into the table while the data which was present for grp2 during the very first deployment, gets deleted from the database.

Any reason why would it insert the data in the very first deployment and later on deleting it from database?

Thanks,
Sumit

Rick Poulin

Check your DD log file. It's quite possible that grp2 executes before grp1 because DD doesn't guarantee the order of groups that don't have an explicit parent/child relationship. Regardless, having multiple groups deploying to the same table for the same record and PK just doesn't work. Like I said, use a composite PK that maps to different XPaths in your record, or change your design.