[RFE] Support renaming a file - example with recommendation of changing persistence.xml file to application.properties

[jwmatthews]

This issue is tracking our ability to detect and execute when the LLM tells us that a given file should be renamed/moved.

For this specific example we would want to:

1. Create a new file src/main/resources/application.properties
2. Update src/main/resources/application.properties with entries derived from the older src/main/resources/META-INF/persistence.xml
3. Remove the older src/main/resources/META-INF/persistence.xml

See src/main/resources/META-INF/persistence.xml from coolstore sample and recommendation to change its contents and rename/move to application.properties

# This file should be renamed to application.properties
quarkus.datasource.jdbc.url=jdbc:mysql://localhost:3306/coolstore
quarkus.datasource.db-kind=mysql
quarkus.datasource.username=root
quarkus.datasource.password=password

quarkus.hibernate-orm.database.generation=none
quarkus.hibernate-orm.sql-load-script=import.sql
quarkus.hibernate-orm.show-sql=false
quarkus.hibernate-orm.format-sql=true
quarkus.hibernate-orm.use-sql-comments=true
quarkus.hibernate-orm.jdbc.use-get-generated-keys=false

Note this is both rename AND move, as persistence.xml was under src/main/resources/META-INF/ and we are moving up 1 directory, so no longer under META-INF

[rszwajko]

@pranavgaikwad
On the IDE side we anticipated this functionality and introduced following Change type inspired by Git extension types.

export interface Change {
  // relative file path before the change, may be empty if file was created in this change
  original: string;
  // relative file path after the change, may be empty if file was deleted in this change
  modified: string;
  // diff in unified format - tested with git diffs
  diff: string;
}

Can you send array of such objects instead of the current response?

// current types
export interface SolutionResponse {
 diff: string;
 modified_files: string[];
 // ...other fields
}

[pranavgaikwad]

@rszwajko Note that we have not talked about adding the rename feature yet for the mvp (probably won't). But from an api standpoint, this makes sense to me.

[shawn-hurley]

I think that this is in the same vein as #218 and believe that they should become a single issue.

We need to handle file operations as part of the output of an LLM (rename/remove) and (rename/update contents).

Thoughts about repurposing one of these issues and re-naming to capture the fulll scope or can we create a tracking issue that links both of them.

[pranavgaikwad]

I agree, @shawn-hurley this is part of that bigger effort indeed