tracker issue | What iT iS dESign studios

Title:

Manage Colelction Values not saved

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/NotABug

Reporter/Name(from Bugbase): Derek Bowes / Derek Bowes (Derek Bowes)

Created: 02/19/2013

Components: Administrator

Versions: 10.0

Failure Type: Data Loss

Found In Build/Fixed In Build: Final /

Priority/Frequency: Major / All users will encounter

Locale/System: English / Platforms All

Vote Count: 1

Problem Description: When going into Data & Services > ColdFusion Collections > Manage Collection when editing a collection, the values last input for that collection are not saved. The return to the defaults.

Steps to Reproduce: Go to CF Administrator >Data & Services > ColdFusion Collections > Add New Solr Collections enter values that are not the defaults. Save and go back into that collection and the defaults will reappear.

Actual Result: Saved values are overwritten by defaults.

Expected Result: Saved values should appear.

Any Workarounds: None. But I don't think it affects the actual collection itself, just what is displayed.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3502465

Deployment Phase:	Release Candidate

External Customer Info:
External Company:  
External Customer Name: dabinaz
External Customer Email:  
External Test Config: My Hardware and Environment details: Win 2k8 64bit

Attachments:

Comments:

Bug Verified.
 (Comment added from ex-user id:vnigam)

Comment by Adobe D.

16274 | May 27, 2013 03:36:50 AM GMT

I understand that the page you are referring to is little confusing. This page is used to index documents and add to the collection. One can index any number of directories and add to the collection and therefore it does not make sense to show the directory path that was indexed last time. It is not a bug as such.

Comment by Rupesh K.

16275 | January 02, 2014 04:49:05 AM GMT

This is a big issue, as if an edit needs to be made, the original indexed content is unknown.  Either adding a folder or file extension, or removing a folder or file extension - if the original criteria is unknown/forgotten, then the edit cannot be completed.

Any progress with this?  I have collections that another developer created and did not document.  If the client wants to make a change, I have no idea what's currently being indexed.

Comment by External U.

16276 | September 02, 2014 08:59:06 AM GMT

Would have thought this would be implemented a long time ago.

Vote by External U.

16291 | September 02, 2014 08:59:29 AM GMT

@WolfShade - According to "them" it is not a bug. Go figure. It's a huge PITA as you have just encountered!

Comment by External U.

16277 | September 02, 2014 09:07:21 AM GMT

I am working on a project that was started and completed by a developer who is no longer here. It uses a Solr collection that is not on my development system. I cannot create the Solr collection for it because I DO NOT KNOW WHAT THE COLLECTION IS INDEXING!!!!!!!!!!!!!!!!!!!! I cannot contact the developer who originally worked on this project, so I cannot ask him what this is supposed to index (assuming said developer can even remember what it's supposed to index.)

This is becoming more and more of an issue. Why can we not edit Solr collections? Why is it that when you click on a collection, it doesn't show you what is being indexed? Why does "editing" a collection just give you the default "*.htm, *.html, *.cfm, *.cfml"???

Comment by External U.

16278 | December 08, 2014 09:11:30 AM GMT

I disagree, Rupesh. The collection should not be a blackhole: the UI should list what has been set to be indexed within the collection. Even if not via that UI, it should - at any rate - be possible to extract from the collection what it's indexing.

Comment by External U.

16279 | December 09, 2014 04:08:57 AM GMT

Adam's assertion is absolutely correct, Rupesh. Can you imagine a firewall whereby you add IP addresses for block/allow, but then cannot edit them, or even see what IP addresses have been put in the ACL?  It's kind of like that.

Comment by External U.

16280 | December 10, 2014 12:48:45 AM GMT

@WolfShade, that is not a good comparison. A better comaprison would be a zip file. Create a zip file and keep adding all sorts of files - thousands of it, from multiple locations over a period. The zip can never tell you from which location the files were added to it. It can not tell you what was the filter criteria you had used for selecting the files that needed to be zipped. It just knows the files that are zipped in it. 
Collection is exactly like a zip. In fact it is even trickier - because it can contain not only the files but also the data from database. 
At best, the index can tell you all the data and its keys that are indexed in it. 

@Adam, collection is not like a directory watcher which will know the directory and keep watching the files and index them on a regular basis. Indexing one particular files is a one time operation which you can do from the admin UI or programmatically using cfindex. See the explanation above.

Comment by Rupesh K.

16281 | December 10, 2014 01:53:18 AM GMT

That's specious, Rupesh. Even with your own zip file analogy... you can get a manifest of what's *in* the zip file, and *any* zip client provides that. I can't see how one can extract that information with any of <cfindex>, <cfsearch> or <cfcollection> (I did not look very hard, and I've not used this stuff for years, so am rusty).

This is what WolfShade is asking for, yes?

That said, even if they wanted the manifest of what went *into* the collection, that would be reasonable. How can they do disaster recovery if they cannot extract that information? Are you telling me that neither Solr nor the underlying Lucene stores this info anywhere? Interesting.

Comment by External U.

16282 | December 10, 2014 02:52:58 AM GMT

@Adam, I don't think you read my comment completely. Please re-read. You are saying the same thing that I said.
I said that zip only knows what is *in* the zip. It does not know what were the source folders or the filters used.

I also said "At best, the index can tell you all the data and its keys that are indexed in it." If you have used cfindex and cfsearch, you would know that the key will be either the file name or the primary keys for DB. It would not tell which directory you had decided to index or which filter (.htm, .pdf, ,doc etc) you used to choose the files. 

I will ask Uday to check and share how exactly one can retrieve the information for all the keys from the index. Depending on that finding we can explore if we can provide a function to get this information.

Comment by Rupesh K.

16283 | December 10, 2014 03:14:57 AM GMT

I did read it all, Rupesh. I was weeding away the rest of the rubbish you were spouting to justify your position of indolence around the few words of sense you managed to include.

95% of what you typed was specious work-avoidance justification.

However you finally got it right with this bit: "I will ask Uday [etc]".

Cheers.

Comment by External U.

16284 | December 10, 2014 03:27:39 AM GMT

Oh well, there you go! Again!

Comment by Rupesh K.

16285 | December 10, 2014 03:58:11 AM GMT

I beg your pardon?

I tell you what, Rupesh. As soon as you stop just trying to deflect work with nonsense excuses, I'll stop calling you on it.

Comment by External U.

16286 | December 10, 2014 04:14:46 AM GMT

Look Adam, if you want a positive discussion, I am all for it. But I don't think you want that, do you? 

Everything I said earlier in the thread was a fact and not an opinion. Please explain how that was a nonsense excuse. This thread is closed for me and don't expect any more response.

Comment by Rupesh K.

16287 | December 10, 2014 04:55:10 AM GMT

Why is this so hard to implement? Store the settings and read them back. done. The firewall analogy was spot on. Not the zip analogy.

Comment by External U.

16288 | December 10, 2014 07:46:44 AM GMT

If it was just a matter of storing the settings, we would not be having any discussion here.

You should first try to find out what the "index" is before concluding which analogy suits it. You create a collection, then you index files/database data using cfindex (or from the admin UI) and the indexed data gets stored in the collection. You can index thousands of files or database rows and all those data will get indexed and go in the collection. Storing the parameters of cfindex tag in a configuration file everytime cfindex is called is not at all practical. It would actually be a log, isn't it which we already have.

May be what we can do is - have another separate log files for each collection which lists the parameters for each cfindex call. Would that make sense?

Comment by Rupesh K.

16289 | December 10, 2014 08:06:23 AM GMT

If it can be retrieved via CFAdmin or returned as an attribute from a cfsearch tag, yes.

If the only way to get that information would be to open a log in CFAdmin, that's not as convenient, but better than saying it can't be done.

There's also the fact that in ColdFusion Collections, there is an icon that when the cursor hovers over it will produce a tooltip that says "EDIT".  This annotatively implies that the information is present and can be manipulated directly.  To simply provide the default ".htm, .html, .cfm, .cfml" and no folder path is counter-intuitive.  Makes no sense.  Everything else that I've ever encountered that is labeled "EDIT" will present the user with what is currently in place, and will allow said user to manipulate the settings/data/content - instead of forcing the user to enter everything from scratch.

Comment by External U.

16290 | December 10, 2014 04:46:40 PM GMT

Another analogy would be a CMS.

If a news organization used a CMS to enter news articles for the consuming public, but the CMS provided an EDIT feature that presented the editor with a blank textarea, that CMS would not be used for very long.  The CMS that is desired is the CMS that grabs the content of an article from the database and presents the editor with that value so the editor can actually _EDIT_ the content, not an empty textarea.

It is now 2018.  Has this continued to be ignored???

Comment by Jack D.

29982 | November 28, 2018 07:10:17 PM GMT

I am the originator of this debacle. It's so sad. Everyone should just start switching to Lucee.

Comment by Derek B.

29983 | November 28, 2018 07:27:06 PM GMT

Hi all,

Rupesh is right. cfindex indexes files -and- queries. Even if CF stored the cfindex attribute values into a config file, that'd only be helpful for the former (files) but not the latter (queries). Meaning, the files could be re-indexed (b/c the config would have the file/directory paths/extensions) but not the query variables (b/c the config would not contain a copy of the query variables).

+1 to Rupesh's suggestion, which was: "May be what we can do is - have another separate log files for each collection which lists the parameters for each cfindex call."

Adobe could you please re-open this ticket and please consider Rupesh's suggestion (collection-specific log files that list each cfindex call's parameters)?

Thanks!,
-Aaron

Comment by Aaron N.

29995 | December 04, 2018 05:15:16 AM GMT

tracker issue : CF-3502465

Manage Colelction Values not saved