data column in tasks table #6

New Issue

k2s · 2022-06-18T19:04:53Z

k2s commented

2022-06-18 19:04:53 +00:00

I would need data column in tasks model.
It would be similar to description, but would not be visible for user.
It would contain free JSON that could keep machine readable data realated to the task.

For example it could store reference to Curo record which caused this task to be created, but it could store also information to be used by Curo when task is marked as done (see #5).

I would need `data` column in `tasks` model. It would be similar to `description`, but would not be visible for user. It would contain free JSON that could keep machine readable data realated to the task. For example it could store reference to Curo record which caused this task to be created, but it could store also information to be used by Curo when task is marked as done (see #5).

k2s added this to the Curo integration project 2022-06-18 19:04:53 +00:00

konrad commented

2022-06-18 19:09:35 +00:00

I thought about using attachments for this and basically allowing attachments to be everything, not only files. That would come in useful for other integrations as well (like adding a reference to a PR to a task in Vikunja).

k2s commented

2022-06-18 19:13:26 +00:00

My comments against using attachemnts:

requires again something like hide_on_ui flag
much slower data retrieval then to have it in tasks model
PaTCH method for this field could help with extendability (would merge new JSON with existing data instead of replacing)

The point is, that this field doesn't need to be indexed, nor understood by Vikunja API server, but is needed for the entity received the task data.

My comments against using attachemnts: * requires again something like `hide_on_ui` flag * much slower data retrieval then to have it in tasks model * PaTCH method for this field could help with extendability (would merge new JSON with existing data instead of replacing) The point is, that this field doesn't need to be indexed, nor understood by Vikunja API server, but is needed for the entity received the task data.

k2s added the

API

label 2022-06-18 19:13:35 +00:00

konrad commented

2022-06-18 19:18:55 +00:00

The point is, that this field doesn't need to be indexed, nor understood by Vikunja API server, but is needed for the entity received the task data.

That's what I thought. The API would allow either file attachments which behave like the current ones or something else entirely. The api would return all attachments and the frontend would need to decide what to evaluate or not. The response would look something like this:

{
	"id": 1,
	"title": "Test task",
    "attachments": {
    	"file": [
        	...
        ],
        "something else entirely": {
        	// arbitrary json data
        }
	}
}

You could then tell the api "hey update whatever I have stored as the something else entirely attachment type and it would just store that as a json blob, maybe merging with other stuff.

Maybe that's just me overengineering things but I think this would be a nice abstraction.

> The point is, that this field doesn't need to be indexed, nor understood by Vikunja API server, but is needed for the entity received the task data. That's what I thought. The API would allow either `file` attachments which behave like the current ones or `something else entirely`. The api would return all attachments and the frontend would need to decide what to evaluate or not. The response would look something like this: ```json { "id": 1, "title": "Test task", "attachments": { "file": [ ... ], "something else entirely": { // arbitrary json data } } } ``` You could then tell the api "hey update whatever I have stored as the `something else entirely` attachment type and it would just store that as a json blob, maybe merging with other stuff. Maybe that's just me overengineering things but I think this would be a nice abstraction.

Sign in to join this conversation.

No Label

API

UI

No Milestone

No project

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: k2s/populate-vikunja#6