If I insert a new document into RavenDB using a put command and specify it's key, the first time it is simply inserted as expected. However, the second time I run the same put command with the same key, but altered data there is a new document created, I was expecting the existing document to be updated.
This seems to come from the fact that the document key has an incrementing number attached to the end of it (not by me, I guess the raven client is doing it for me).
How can I prevent the additional number from being appended to my document key so that a put command updates rather than creates a document?
You can't create keys with a / in the end.
See the docs here: http://ravendb.net/docs/theory/document-key-generation
Related
I store scraped content within a csv file.
Each row contains a unique ID and description of an item.
My ID is coming from the website where I scrape the content and not generated on the scraper side.
I use Scrapy's feedExporter to generate the csv file
When I scrape again my website, I would like my script to check if unique ID is already stored within the csv file, if it's not I would add the new row, if it is I will just move on to the next item.
As I assume this is a classic thing to do with a scraping framework I believe there must be a smart way to do it with Scrapy however I can't find anything on this topic within the Scrapy's documentation
Should I simply open the csv file, go through each item and if iterator's value not present add a new row or skip if it is?
One solution might be to create an empty HashMap. Then on the first scan, put your items in the HashMap. HashMaps do not hold duplicate values. So in light of this on your second scan, look up the key, and if the key exists, onto the next. If it doesn't exist, add it.
I copied a new version of a table into an existing vfp installation and when it then tries to access that table it comes up with a variable not found error. The old version and new version of the table appear to have the same structure. Why could this happen? Does the dbc need to be updated in some way if I copy a new version of the table in. The structure is the same, but the data in it is different.
I copied the table in in Windows Explorer.
If the DBC in the same folder as the table? If not, are they in the same relative position on the two different drives? If not, you'll get errors, though I wouldn't expect "Variable not found."
Did you bring along the FPT and CDX for the new file? Again, that's not the error I would expect, but failure to do so would cause problems.
Assuming all that is right, what's the actual line of code that's failing?
Was the table that you've copied in "freed" from it's previous DBC before copying? If not, as soon as you attempt to USE it in the new location then I believe VFP will try to locate the DBC that it belongs to.
If you believe the table structure to be identical then you might be better off leaving the existing one in place and just ZAPping it to clean it out then appending the records from the other copy... of course you might need to temporarily switch off any INSERT triggers or row-level validation if you've got anything clever happening therein such as updating a "last modified" field. AutoInc fields will also need to be handled with care too, but it doesn't sound like this is something you're expecting to do on a regular basis so shouldn't be too onerous as a one-off exercise.
I have indexed approximately 1000 documents in Solr. But all of them are missing a field. I need to add a field to all these documents, and this field will have the same value for all of them. I do not have access to these documents to index them again. Is there any way to do this without re-indexing all the data again?
Unless you've configured your schema to store all values, no, there is no usable way to add a field to the documents without reindexing. If you all fields are stored, you can use atomic updates to add a new field for a document, so you could query Solr for the ids of all existing documents and perform an update that way.
Otherwise you're going to have to go with the suggestion from #michielvoo, and return a static value from the query string .. but then you could also just append it in your application before returning it to the user (or, you could add the field as a default value for the request handler in solrconfig.xml, so that you can edit and change it server side).
Im building a key inventory mgmt system. I've created a query that show's me keys currently not in use by identifying which keys have been returned, aren't lost or have never been rented. I copied this query into the look up field for key_id in my keyActivity table (used to record key sign outs). The issue is that the query does not update to provide available keys until the table keyActivity is closed and opened again
Example: I open keyActivity, indicate that key_id = 5 is lost. When I go to a new record and select the key to sign out, key_id = 5 is presented as being available. It is not until I close the table, open it again, that key = 5 is removed from the list.
Here you can see key 5 is indicated as lost in id 5 but in id 7 when selecting a key, 5 is available when it shouldn't be.
Is there anyway to fix this or set this up to work as intended. I plan on using forms to present all the information. Is there a form solution perhaps?
The suggestion you would be better off with a Form to change table data. It can be easily requery-ed to update the table according to the changes you make and to display the udpated data accordingly. Please also read on the given references for further info.
In terms of data updating and locks in a multi user environment this article could be helpful.
"Access is NOT a database server. It's a desktop database. It has been pushed to the limit to support mutli-user environments, but only in the sense that you can share the "back end" database across a network."
...
...
"Even the record locking is performed by the Front End. All of the front end
database applications share the "lock file" (a file with the same name as
the database file, but with the extension LDB); but that file is simply a
mechanism that the front ends use to determine which front end can make
changes to the database."
....
Here is a difference between requery and refresh:
Me.Requery forces the entire recordset (underlying data) for the form to reload. This means ALL of the records in your current form will reload. Your current position will be lost, so if you're sitting on record 10 of 100, you'll find yourself back on the first record. Me.Requery is essentially the same as closing and reopening the form. Any new records added by other concurrent users will be available. Likewise any records that have been deleted will disappear. Requery essentially "re-runs the query" that pulled the data into the form in the first place. You can also use requery to update the data in a list box or combo box.
Me.Refresh saves the current record that you're working on. It will also retrieve any changes (but not additions or deletions) to any records shown in the current form. Any calculations on the form (unbound fields) are recalculated. Refresh does NOT reload the recordset. You do not lose your position in the form (you stay on the current record). Any new records added by other users will not be shown.
Reference
MS Access - Write to Table Immediately After Changing Value in Form
I've been tasked with learning Lotus Domino Designer - not sure what I did in a previous life, but it must have been pretty bad... - and was wondering how to do a lookup on a database to get some values for selections. As this information could potentially be used in a lot of the applications, I'd prefer it only to be in the one place.
I gather I can use #DBColumn, but what happens if an entry in that lookup changes? If the unique value of the lookup is the text, then the relationship would be broken, wouldn't it? Is there any way of mimicing the idea of relational lookups?
I'm assuming I'm looking at Lotus development from the wrong angle, as this seems to be a real limitation of look ups.
I haven't found any decent learning material on the interwebs, so would appreciate any help.
Ta
You would want to store a unique ID along with the textual value in the source database (not unlike what you would do in an RDBMS). Then, only store that ID in any referencing documents, and use a computed-for-display field to lookup the display value. (There is a performance consideration here - and you could "de-normalize" the data and store the ID and text value in the referencing documents, and do some asynchronous work to keep the values in sync - eg: using a scheduled agent that runs every night or every week).
If DB1 has the key values and DB2 has the documents which will reference these values, then in the form in DB2, you would still do a #DbColumn to lookup your value list. In the lookup view in DB1, concat the text value and ID with a pipe separator (textField + "|" + ID) in the first column. That will tell Notes to store only the ID value (what follows the pipe is the "alias" and is what will be stored).
Note: I would avoid using #DocumentUniqueID as the unique ID for these values, as the Document Unique ID will change if the documents are copied and pasted, or the entire database is copied, etc. You can use the #unique formula function in a computed-when-composed field to generate something close to a unique ID (almost like an identity column in sql).
If you need relational properties, look for non-Notes solutions. It is possible to get some relational behavior using document UNIDs and update agents, but it will be harder than with a proper relational backend.
Your specific problem with referencing to a piece of text that might change can to some extent be resolved by using aliases in the choice fields. If a dialog list contains values on the form...
Foo|id1
Bar|id2
...the form will display Foo but the back-end document will store the value id1 - (and this is what you will be able to show in standard views - although xpages could solve that). Using the #DocumentUniqueID for alias can be a good idea under some circumstances.
It depends on where your using the data. The #DBLookup or #DBColumn will work in Lotus Notes fields if the fields are set to be computed for display. That way they always get the most up to date information when you open the form etc.
If you make it so the data is saved on to the document then you will have to write some update code when you need to refresh the values.
The Lotus Notes help files for designer are pretty good, have a look at that.
SM
You could use a key or alias to store the relationship to your lookup value so if the value itself changes, the connection remains because the alias is intact. For example, if your lookup values were being stored as a collection of documents, I'd have the #DBColumn retrieve Document UNID|lookup value pairs. When in display mode, you could then retrive the value using #GetDocField. If the lookup values are in a different database, then you'd have to retrieve them for display using #DBLookup and construct a view that is keyed off of the UNID or whatever key you decide to use.The only drawback to this technique is that you wouldn't be able to display the field value in views as the actual value isn't stored in the document, just a reference to it. Using XPages, though, you COULD map the relationship into a dynamic datatable just like you would in a truly relational system.
It's tricky, but using LEI, you could also use Notes to front-end a relational backend system, also giving you the dynamic relationship you desire in your lookups.
Hope this helps!
The content of the lookup can change freely. A problem only arises (as it would on any other platform in the same circumstances) if the lookup key changes. You need to use a key that won't change. Human-readable text is an advantage, but if you want to be able to change your key description from, say, "Divisions" to "Business Units" and still have lookups work, you need to use an alias of some kind, which will presumably be mapped to your text description and only used internally. #Unique is pretty good for this, and gives a shortish key, if that is important to you. #DocumentUniqueID is most reliable, but as Ed pointed out, will change (must change - it's a new document) if you copy/paste or make a non-replica copy. This is easy to get around, though. Create a Computed-when-composed field (called, say, "LookupRef") on the form you are using for your reference document with the formula "#DocumentUniqueID". That will capture the ID at the time of creation, and it will not change on copy/paste etc. Use that as your key.