For a while we've had two different Store replicators in the distribution. One is the original one, which John Brant wrote way back, which uses the Store facilities. The other is a Glorp-based one that I wrote. Having both is a bit confusing, and the original one hasn't been maintained in a while as far as I know, and we've seen a couple of issues with it not keeping up with Store changes. The Glorp one is in quite heavy use, including internally by us. So my thinking is that we should remove the older one from the distribution.
However, I'd also forgotten that I wrote the ExportDatabase facility using that replicator. This allows you to write out a .dbt file that's small and portable, and contains just one or a few versions. The way it's written it isn't immediately portable to use the other replicator. If you're curious, it's got a really (really) minimal SQL interpreter in it which is enough to handle the SQL that the older Store facilities write, but not enough to handle the SQL that Glorp writes. I've thought about doing another version of ExportDatabase that would do something different, for example just BOSSing out the StoreGlorp domain objects, or perhaps the rowmap. But I haven't done it, and I don't see myself having a lot of free time in the next while to do so. You could, however, accomplish the same thing by writing out the data to a file-based database like SQLite. So my question is if there are people using the old Store Replicator, or ExportDatabase, who would object to their removal. They will of course, remain in the public Store, so it's not like you couldn't load them. I'm just talking about their presence as parcels in the distribution. -- Alan Knight [|], Engineering Manager, Cincom Smalltalk [hidden email] [hidden email] http://www.cincom.com/smalltalk _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
To respond quickly...
The ControlWORKS team at Adventa (we) rely upon both products. I suppose we could live with the Glorp-based replicator if it were enhanced a bit. One problem I saw with the application is that it acts upon the items selected for replication immediately, rather than allowing me to compose a list (correct, and add to this list) before acting upon it. A go button would be helpful, or some way to instruct it to not act immediately if I choose to use it in that way. With this aspect of the product changed we could easily move to the newer faster replicator. As for the ExportDatabsae facility... I'd rather not have to rely upon an SQLite solution since this adds a dependency. I'd prefer to have some way to supply patches (bundles with explicit versioning) without having such an additional requirement. The dbt file format was a great solution that doesn't add any additional dependencies. I propose that you keep both utitlites until such a time as you have a replacement to the ExportDatabase facility which utilizes the GlorpReplicator in a way that the current ExportDatabse facility utilizes the older StoreReplicator. Thanks much, -Steve Alan Knight wrote: > For a while we've had two different Store replicators in the distribution. One is the original one, which John Brant wrote way back, which uses the Store facilities. The other is a Glorp-based one that I wrote. Having both is a bit confusing, and the original one hasn't been maintained in a while as far as I know, and we've seen a couple of issues with it not keeping up with Store changes. The Glorp one is in quite heavy use, including internally by us. So my thinking is that we should remove the older one from the distribution. > > However, I'd also forgotten that I wrote the ExportDatabase facility using that replicator. This allows you to write out a .dbt file that's small and portable, and contains just one or a few versions. The way it's written it isn't immediately portable to use the other replicator. If you're curious, it's got a really (really) minimal SQL interpreter in it which is enough to handle the SQL that the older Store facilities write, but not enough to handle the SQL that Glorp writes. I've thought about doing another version of ExportDatabase that would do something different, for example just BOSSing out the StoreGlorp domain objects, or perhaps the rowmap. But I haven't done it, and I don't see myself having a lot of free time in the next while to do so. You could, however, accomplish the same thing by writing out the data to a file-based database like SQLite. > > So my question is if there are people using the old Store Replicator, or ExportDatabase, who would object to their removal. > > They will of course, remain in the public Store, so it's not like you couldn't load them. I'm just talking about their presence as parcels in the distribution. > > -- > Alan Knight [|], Engineering Manager, Cincom Smalltalk > [hidden email] > [hidden email] > http://www.cincom.com/smalltalk > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Thanks. It sounds like we ought to keep them.
At 11:25 AM 6/5/2009, Steve Whitson wrote: To respond quickly... --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |