Questions on workbench versioning

[Elaine_Schmitz]

I learned the hard way that one should not really be using designer in workbench to modify forms, due to the version incrementing with each save and possible database bloat that could result.  Knowing that, the following questions come to mind:

1.  Can I limit the number of versions of a form that are stored?
2.  Can I clean out older versions of a form??
3.  When I delete a form (or file) from the resources pane, let's say it's at version 15, are all previous versions of that file deleted too?  Or do they hang around in the tables as orphans?

If the answers to questions 1 and 2 are "no", then I would really like to see a utility, perhaps in adminUI, to handle this.

Thanks!

Elaine

[Former Community Member]

1.  Can I limit the number of versions of a form that are stored?

No.

2.  Can I clean out older versions of a form??

Yes.

3.  When I delete a form (or file) from the resources pane, let's say it's at version 15, are all previous versions of that file deleted too?  Or do they hang around in the tables as orphans?

No. They are in the repository but they are not orphans.

The current product has no administrative UI for managing the native repository. You can administer the repository through the Java API or the Web Service API, however.

Repository Service API Quick Starts

http://livedocs.adobe.com/livecycle/8.2/programLC/programmer/help/000175.html

Working with LiveCycle ES Repository

http://livedocs.adobe.com/livecycle/8.2/programLC/programmer/help/001555.html

Steve

[Elaine_Schmitz]

Thanks Steve, In regards to your answers then, can you please advise the

following?

Expanding on questions 2 and 3:

2) How does one clean out older versions of a form out of the system

tables? Would we need to manipulate the sys tables directly?

3) If you delete a file from the respository, and the previous versions

are not deleted automatically, then that contributes to sys table bloat,

right?

The word on the street is that we shouldn't have our hands in the system

tables. Therefore, we need a tool to manage that. Which is why I would

like to see that offered through the adminUI or via workbench perhaps. I

mean, I personally like to know that my sys tables are clean. The way it

works now is a little messy, in my opinion.

Thanks,

Elaine

[Former Community Member · Accepted solution]

2) How does one clean out older versions of a form out of the system tables?  Would we need to manipulate the sys tables directly?

Through an API. Yes, hitting the tables directly could cause significant problems.

Through the API you can query and report on the resources in the repository, analyze the resources, and ultimately, delete resources using  deleteResources() with the list of IDs (unique IDs or logical IDs). The API provides access to all the resource metadata you would need to validate the resources for deletion. See the Resource class in com.adobe.repository.infomodel.bean

3)  If you delete a file from the respository, and the previous versions are not deleted automatically, then that contributes to sys table bloat,

right?

Absolutely.

On a similare note, there is a purge tool shipped with the product to delete long-lived processes from the database. The purge tools is available

C:\Adobe\LiveCycle8.2\LiveCycle_ES_SDK\misc\Foundation\ProcessPurgeTool

Steve

[Elaine_Schmitz]

Thanks Steve for your thorough responses.  I will mark this question as answered, however I need to conclude with the following statement that I am really concerned about not having the ability through adminUI or wherever to keep these tables clean (I will try the purge utility to see how that works).

We are in the process of migrating a ton of local forms to workbench, and because we're using an agile process, we will be hitting these forms over and over again - meaning we will be continually replacing artifacts on the server.  With my early experience, I am not sure of the best way to migrate forms/frags, etc except to always delete them from the server first and then re-merge the newer local files to the server (so that I will avoid this "bloat" issue).   I don't want to have too many versions building up on the dev server and I don't think I should have to write an API to keep the tables clean ;-)

This is something that should be provided as a utility from adobe!  Am I the only one that considers this a serious concern?

Will the purge utility delete older versions of files that are no longer associated with a process?

Thanks,

Elaine

[HowardTreisman]

Hi Elaine

I had a quick look at the APIs.

There is no exposed API for removing old versions.

Therefore there is no way (at the moment) that anyone could write a utility for purging old versions.

I suspect your proposed approach (i.e. delete the entire resource before uploading a new version) would be the best way to go.

There may (probably is) a private API for removing old versions, but similarly to directly manipulating the database tables, it's probably not a good idea.

Although if you feel this is a really major issue, we could do some more digging...

(I did have a look at the table structure also, and I'd be nervous about manipulating it directly. Might be okay to risk on a dev server, but I wouldn't do it on production.)

I also very much doubt that the Adobe purge utility would purge old versions of resources - it only purges old versions of process instances.

And I know that the Avoka purge utility will also not purge resources.

Sorry...

howard

[Former Community Member]

I beg to differ.

Unless I am completely misinterpreting the methods deleteResource and deleteResources, there is a rich set of methods to manage the repository in the ResourceRepository interface.

http://livedocs.adobe.com/livecycle/8.2/programLC/programmer/javadoc/com/adobe/repository/bindings/R...

Steve

[HowardTreisman]

Hi Steve

My understanding is that deleteResource deletes the entire resource, with all its versions.

What Elaine wants to do is to delete old versions of a resource, but retain the most recent version. (Elaine, please confirm.)

You can get old versions of the resource using getHistory, but there is no way of removing old versions.

Howard

[Elaine_Schmitz]

Mostly correct, Howard. Here's my dilemma. Because I am currently

working locally on jboss, the sys tables are stored locally and I don't

want extra forms / files sitting in there unnecessarily. Unfortunately I

can't do anything about this giving the capabilities of the current tool.

Additionally, I don't think it's the end-users responsibility to write an

API to manage that aspect of the system tables - I strongly believe that

that is the responsibility of the tool (or adobe) to provide us with these

utilities.

Because of the limitation, I am changing how I move artifacts to the

server. I end up deleting a resource on dev first, and then replacing the

resource by dragging it back in there. But if I delete a resource that is

a fragment, and drag the new fragment onto the server (same name, same

relative path), the form that uses the fragment is now in a broken state

because it can't resolve to the fragment path even though the relative

pathing is correct. Now I have to edit the form on the server (in

workbench), repoint to the fragment and save the form. Now I have version

1.1 of the form, and can't delete version 1.0! I hope that makes sense.

We have a search fragment that will be sitting inside of every form we

develop. The search fragment is very volatile right now as it is in a

state of development / change. So as we keep changing it and replacing it

on the server, I don't want to have to modify every form that uses the

fragment.

So as you can see, this is getting to be a real issue for me.

If there's a better way for me to manage server resources and keep the sys

tables from bloating, please let me know.

Thanks,

Elaine

[HowardTreisman]

Hi Elaine

1. Yes, I agree, this isn't something you should need to code up yourself, it should be part of the product. My understanding is that this area is targetted for improvement in the next version, but you may want to log a feature request with Adobe to make sure it works the way you'd like it to.

2. I'm very surprised that deleting a fragment and then re-uploading it "breaks" the linkage. Are you sure? Are you using PDF for XDP as your file type?

Howard

[Elaine_Schmitz]

Hi Howard,

We are using xdp files. I think if you close workbench and reopen, then

the form will re-establish a link to the newly replaced fragment. But

that's a pain too.

You want to run a test and prove me wrong?

I'm overwhelmed this evening, because we're also suffering from the "huge

LC file size" issue (http:// blogs.adobe.com/livecycle/2009/03/post.html).

I've never struggled so much with a new product in my life, sigh.

Thanks,

Elaine

[HowardTreisman]

Um, I don't quite get it. (And no, I haven't tested this...)

Are you saying that if you:

1. Delete the fragment
2. Upload a new version of the fragement
3. Open the XDP form that refers to the fragment

--> You get the old version of the fragment?

   4.   But if you close workbench, then open it again, and then open the XDP form

--> You get the new version of the fragment?

If that's the case, it sounds like a simple caching issue in Workbench - it's not refreshing the cached copy of the fragement.

And in fact, this actually makes sense, because the version number of the replaced fragment is the same (or lower) than the original fragment.

Is this what you're saying?

The really interesting issue is whether this same caching problem will occur on the server when you render the form?

Howard

[Elaine_Schmitz]

>>>See Inline comments... Thanks Howard

Are you saying that if you:

1. Delete the fragment

2. Upload a new version of the fragement

3. Open the XDP form that refers to the fragment

--> You get the old version of the fragment?

>>>>>No, it has nothing to do with the fragment,... when I opened a form

that houses the fragment, it shows the form with the "broken fragment"

symbol. The form didn't resolve to the new uploaded version even when the

relative pathing was the same as the old.

4. But if you close workbench, then open it again, and then open the

XDP form

--> You get the new version of the fragment?

>>>>No, the form was able to resolve to the new fragment properly.

[HowardTreisman]

Sounds like a bug to me. Or at least some "behaviour" that isn't optimal. I'd log this with Adobe support.

Howard