[7.8] TW_ParcelRecord constraints

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[7.8] TW_ParcelRecord constraints

Randy Coulman
I'm in the process of converting my personal Store repository from PostgreSQL to Sqlite.  When attempting to replicate my data from the old to the new, I'm running into some failed constraint errors.

As near as I can tell, it's failing because of the version column of TW_ParcelRecord having a NOT NULL constraint on it.  If I look at that table in my old DB, none of the records have a value in that column.  If I look at the query being generated to insert the data into that table, the version column isn't even listed in the query.

My old database doesn't have the NOT NULL constraint on that column, but that database probably dates back to VW 7.5 or 7.6 (maybe older).

Is there a bug somewhere?  How can I get around this problem and get my data replicated over?

Thanks,
Randy
--
Randy Coulman
[hidden email]

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [7.8] TW_ParcelRecord constraints

Samuel S. Shuster-2
Randy:

Is there a bug somewhere?  How can I get around this problem and get my data replicated over?

The field should be not null, however it is possible since old code didn't have that constraint, and did not enforce it in code, that you will have a problem replicating.

There are two solutions:

Solution one is ugly, and twofold:

One, in StoreDescriptorSystem>>addStandardStoreDescriptorTo:forTable:andClass:, change the isNullable: in the line related to version to true.

Two, go to the database itself and remove the non null constraint.

Solution two is E-Z.

update pk_parcelrecord set version = 'NotSet' where version is null;

You probably want to do the same for the columns username and filename


                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, Store Project
Smalltalk Enables Success -- What Are YOU Using?





_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [7.8] TW_ParcelRecord constraints

Samuel S. Shuster-2
In reply to this post by Randy Coulman
Oops, I meant 

remove the isNullable: or change to true in:

StoreDescriptorSystem>>createStandardAndVersionRecordFieldsIn:


                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, Store Project
Smalltalk Enables Success -- What Are YOU Using?





_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [7.8] TW_ParcelRecord constraints

Randy Coulman
Thanks for the help, Sames.

I tried updating that column in my old database as you suggested, but that didn't solve the problem, because the insert query into the new database wasn't specifying a value for the 'version' column at all.  Not sure why that is.

I had already replicated most of my code over, so I didn't want to start over again.  There were no records in tw_parcelrecord yet, so I did this:

sqlite3 <myDatabase>
.dump tw_parcelrecord
drop table tw_parcelrecord;
<replay all of the SQL commands from the .dump above, but edit the CREATE TABLE command to change the 'version' column from NOT NULL to NULL>

Then, I retried the replication of the versions that had failed before, and everything worked just fine.

Again, thanks for the help.

Randy

On Fri, Oct 28, 2011 at 11:18 AM, Samuel S. Shuster <[hidden email]> wrote:
Oops, I meant 

remove the isNullable: or change to true in:

StoreDescriptorSystem>>createStandardAndVersionRecordFieldsIn:


                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, Store Project
Smalltalk Enables Success -- What Are YOU Using?







--
Randy Coulman
[hidden email]

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [7.8] TW_ParcelRecord constraints

Samuel S. Shuster-2
Randy,

Again, thanks for the help.

Well, it turns out that there is a bug in our creation methods for both TW_ParcelRecord and TW_FileRecord. If you change them to read:

StoreDescriptorSystem>>tableForTW_PARCELRECORD: aTable 
| blobId sourceId pundleId foreignKey versionField |
self createStandardAndVersionRecordFieldsIn: aTable.
versionField := (aTable fieldNamed: 'version').
versionField beNullable: true.
"[....]"

and:

Store73DescriptorSystem>>tableForTW_FILERECORD: aTable 
| fileId foreignKey versionField |
self createStandardAndVersionRecordFieldsIn: aTable.
versionField := (aTable fieldNamed: 'version').
versionField beNullable: true.
"[...]"

You'll be MUCH better off. (Or if you have already created 'em, remove the NOT NULL constraint on both of them for the version field).

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, Store Project
Smalltalk Enables Success -- What Are YOU Using?





_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [7.8] TW_ParcelRecord constraints

Randy Coulman
I did remove the constraint from my DB for tw_parcelrecord and got my stuff replicated over.  I didn't run into the problem with tw_filerecord though (I don't have any records in that one).   And, I just checked, it  already allowed NULL for the version field.

I found myself wondering if the version field is even used at all in tw_parcelrecord, and if not, why is it there?  Just curious, and not a big deal.

Randy

On Tue, Nov 1, 2011 at 12:01 PM, Samuel S. Shuster <[hidden email]> wrote:
Randy,


Again, thanks for the help.

Well, it turns out that there is a bug in our creation methods for both TW_ParcelRecord and TW_FileRecord. If you change them to read:

StoreDescriptorSystem>>tableForTW_PARCELRECORD: aTable 
| blobId sourceId pundleId foreignKey versionField |
self createStandardAndVersionRecordFieldsIn: aTable.
versionField := (aTable fieldNamed: 'version').
versionField beNullable: true.
"[....]"

and:

Store73DescriptorSystem>>tableForTW_FILERECORD: aTable 
| fileId foreignKey versionField |
self createStandardAndVersionRecordFieldsIn: aTable.
versionField := (aTable fieldNamed: 'version').
versionField beNullable: true.
"[...]"

You'll be MUCH better off. (Or if you have already created 'em, remove the NOT NULL constraint on both of them for the version field).

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, Store Project
Smalltalk Enables Success -- What Are YOU Using?







--
Randy Coulman
[hidden email]

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [7.8] TW_ParcelRecord constraints

Samuel S. Shuster-2
Randy,

I found myself wondering if the version field is even used at all in tw_parcelrecord, and if not, why is it there?  Just curious, and not a big deal.

In a word: Legacy.

When the schema was created, a bunch of objects were created as subclasses of the abstract superclass StoreSourceObject in the Glorp world, and DBRecord in the OldDatabaseObjects world.

Both of these had 'version' as one of their fields. However, as you see, there is no use (or real meaning to) version for the two objects, since they are always associated with a Package or Bundle, and never stand alone.

A different mistake was made for Blessing, and by necessity carried forward to StoreBlessing, which added "trace" but you don't 'version' a blessing so there is no notion of a parent... there are just a collection of blessings for a Bundle or Package, with one potentially being the 'current' one.

The field is not used, and I want to try to make sure that no repurposing happens in the future, such that these suddenly have meaning where they currently don't.

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, Store Project
Smalltalk Enables Success -- What Are YOU Using?





_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc