Ghost packages?

Feb 17, 2011 at 12:17 AM

Looks like it is very easy to create ghost packages. For example, I try to upload package and run into "access denied". Well, now I'm stuck - if I try to upload it again, I'm getting "package already exists" but it nowhere listed and can't be removed unless I delete record in DB and remove it from "Packages" directory in the gallery.server. Am I missing something?

Coordinator
Feb 17, 2011 at 12:21 AM

Login to the gallery, manage your contributions, delete it.

Feb 17, 2011 at 12:51 AM

It is not listed. Not even under my contributions. Not sure where it gets info about "already exists".

Developer
Feb 17, 2011 at 2:06 AM

Did you look at the bottom? It's in small letters and not very visible (styling issue).

Feb 17, 2011 at 6:12 PM

No, its not there either. I tried to "reset" repository because web client and server got out of sync, and ended up with a lot of weirdness.

Can someone explain what the sync process does? Where it starts, what actually got synced, what files and DB tables involved on both sides? Right now I got one package that I can't remove because it is corrupted and delete would fail. So is this possible manually wipe out all about this package or it is doomed and will be wandering in the repository to the end of times giving yellow screen of death anyone trying to download it?

Developer
Feb 17, 2011 at 7:11 PM

Oh, I just realized that you're referring to your own gallery instance and not nuget.org. Hopefully the gallery experts will have ideas.

Coordinator
Feb 21, 2011 at 1:03 PM

Sorry, for the delay in responding. I'll try to explain the whole cycle that a package goes through from the gallery website, to the server and then back.

When you start a new contribution and upload a package file to the server, the first thing that happens is that the server makes a callback to the website with the user's key and the package Id. The gallery website checks to see if the given key has access to use that package Id. If so, it returns true and the server continues. If not, it then checks to see if that package Id has already been registered. If not, it goes ahead and assigns the given key to that package Id (essentially "claiming" it for that user). It then returns true and the server continues. On the Orchard side, the key/packageId combo is registered in the Orchard_Gallery_UserkeyPackage table.

Once the server has gotten the ok to continue, it extracts the metadata from the package and writes it to the Package table in the Gallery Server database. Control then returns to the website and the data is displayed on the Edit page. Clicking Next on the Edit page will issue an update back to the server, but no new tables are involved at this point and the package is still not published - it simply updates the data in the Package table. Clicking Finish on the final screen (the Screenshots/Logo screen) results in issuing a Publish command to the server. At this point two things happen: 1) The package data is mapped/saved to the PublishedPackage table (this table is what actually exposes the OData feed), and 2) a record is added to the PackageLogEntry table.

The Orchard website runs a synchronization process once a minute. The way this works is that it asks the server for the new records from the PackageLogEntry table (i.e. it passes in the id of the last log record that it processed in order to get any new ones). (Note that the number of log records that the server will return at once is limited based on an AppSettings config entry - 50 by default). The Orchard site then simply loops over the log records that are returned and takes the appropriate action (i.e. Create, Update, Delete, etc.) The actual data for the packages is retrieved via the OData feed. For a new package, it will create a new Package content item in Orchard, which will be written to the Orchard_Gallery_PackagePartRecord table.

So basically, the are 4 tables involved with package data, two each on the server and the Orchard website. Hopefully this helps. Let me know if any of this doesn't make sense or something still isn't clear.

Feb 21, 2011 at 2:25 PM

Thanks Kevin. Critical peace of info that I missed was last uploaded package ID. I have reset repository but remaining old ID prevented new packages from been picked up.