Changing columns

[Thomas Kellerer]

Hi,

I noticed that when changing a column (e.g. renaming it, changing the nullable attribute) the column is now moved to the top of the list of non-PK columns. I find this a bit annoying to be honest.

This has not been the case before, but I don't remember when this started.

Additionally I have the suspicion that changing a non-pk column now results in a changed PK definition.

I'm not sure if this is caused by my recent changes or Joey's. But when I change a column I also get a diff entry (either SQL or Liquibase) that drops and recreates the PK of that table.

Has anyone else seen this?
(If not, it's caused by my changes, and it should be easy to find)

Regards
Thomas

[Thomas O'Brien]

Hi Thomas,

This may have something to do with a recent change I made to the way columns are handled in the primary key. Previously there were fields in the SQLColumn that tracked which columns were in the primary key and their order. To keep these fields in sync with the primary key index, which was being changed repeatedly, a 'normalize' method existed to redefine the ordering of the columns in the primary key. Because we kept running into problems with the normalize method we decided to simplify some of the structure between the SQLTable, SQLColumn, SQLIndex, and SQLRelationship. This ended up increasing coupling between these classes but removed some ambiguity in the events that were being fired between the classes as it was starting to be the case where the order of the events mattered.

Now there is one SQLIndex that is the primary key index of the table. This index will not go away or be recreated as it is a final field in the SQLTable. The index that is defined as the primary key index is also the object that decides which columns are in the primary key. There is checks in place between the SQLIndex and SQLTable to keep the columns in the SQLIndex in the same order as those in the SQLTable.

I have noticed that changing a column attribute does move the column to the top of the non-PKs and I too agree it is annoying. I think the cause is bad logic in the ColumnEditPanel but will have to look into it more.

For the PK index of a column, since the field is final I am not sure about why it would be trying to drop and recreate the index. Could it be possible that the unique id is changing and considering the indexes to be different? We recently added the UUID field to the SQLObjects to track the objects when they get saved to a server. I know there is an outstanding issue that if you add a source database to the server and re-load the project you will get a duplicate of table and schema information. The cause is the tables are being loaded with one UUID and then the database refresh was creating the same table objects with different UUIDs. If the compare is using the UUIDs to confirm if the indexes are equal and is refreshing the database connection so the UUIDs are getting reset this may cause the PK to think it needs to be recreated. If it is comparing based on values in the index then more information may be needed to understand the problem.

Thanks for finding this,

Thomas

--
You received this message because you are subscribed to the Google Groups "Architect Developers" group.
To post to this group, send email to architect-...@googlegroups.com.
To unsubscribe from this group, send email to architect-develo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/architect-developers?hl=en.