[vwnc] Anyone using the old replicator, ExportDatabase

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

[vwnc] Anyone using the old replicator, ExportDatabase

Alan Knight-2
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
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Anyone using the old replicator, ExportDatabase

Steve Whitson
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
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Anyone using the old replicator, ExportDatabase

Alan Knight-2
Thanks. It sounds like we ought to keep them.

At 11:25 AM 6/5/2009, Steve Whitson wrote:
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

--
Alan Knight [|], Engineering Manager, Cincom Smalltalk

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