I replicate data from RavenDB 1.0 database(master) to RavenDB 2.5 database(slave). The replication is done and I query RavenDB 2.5 database with LastModified by using index "Raven/DocumentsByEntityName". I found that the Last-Modified metadata for all documents are updated to today's date so I have no way to get the correct query result. The Last-Modified metadata for the documents in the original 1.0 DB is a date before today.
Is there any way that I can the real Last-Modified date for the replicated documents? or is there any Created-Timestamp in metadata?
Every time the document is updated, the Last-Modified date is reset. It doesn't matter if you did it yourself, or if it was done via one of Raven's own processes such as replication.
If the dates are important for your domain, you might consider adding properties for them to the document itself.
But if all you're after is a creation date in the metadata, you can add one using a custom bundle. You can write your own, or use the one in the Raven.Contrib project.
But no, Raven doesn't keep a creation date on it's own, so if you've already lost the last-modified date then there's no way to get it back.
Related
I think there is a bug when querying a release's ReleaseDate field. Let's say I have a release with a ReleaseDate of 04/24/2017 EDT, when I get the response from the API request, and take a peek at the ReleaseDate field for that release, it comes off as 04/25/2017 (in date time format obviously), one day ahead of the actual date. I am building a calendar app for inside use using full calendar, and this bug is really annoying. Am I correct to say that this is a bug? Are there any workarounds that do not involve writing code to fix the date after querying it? thanks.
Pretty sure this is timezone related. Dates in WSAPI are always UTC. Assuming your workspace is configured for Eastern the dates returned probably are the next day:
A release with an end date of 04/24/2017 is probably being returned from WSAPI with a date like 2017-04-25T03:59:59.000Z, which when converted to EDT would be the end of the day on the 24th.
You'll also want to be specific when setting dates since the backend will again try to coerce the date into UTC if there is no time specified. The current behavior or the detail pages is to set it to noon on that day for that timezone. So something like this: 2017-04-24T12:00:00-05:00
Hope that helps. We did a bunch of work across the product and the api's last year to try to provide a more consistent experience working with timezones. It still can be confusing, but a good rule of thumb is to always be specific and include a time and timezone offset when working with dates using the api.
If you're using App SDK, the moment.js library is already included and is super handy for working with dates:
https://help.rallydev.com/apps/2.1/doc/#!/guide/third_party_libs-section-moment.js-2.10.3
I am trying to use the listdata.svc to retrieve list items and one of the filter parameters is a datetime field. So the request looks like this:
http://moss2010/_vti_bin/ListData.svc/HeadLineNews?$filter=Active
eq true and EndDate ge datetime'2012-01-11T18:00:00'
I am getting items back with "EndDate" set to earlier time back from the request such as the following:
<d:EndDate m:type="Edm.DateTime">2012-01-11T12:00:00</d:EndDate>
I have tried to change the time in the EndDate parameter around in case this has something to do with client browser's timezone settings( I have changed "18:00:00" to all 24 hours between "00:00:00 - 23:00:00"), but this doesn't seem to be making a difference. However as soon as I change the date to a day earlier "2012-01-10T18:00:00", it would start to return correct items.
Is it a known issue for ListData to ignore the time information for DateTime fields? Anybody have run into this before?
I have October 2011 Update on my SharePoint server.
I believe this is a known issue - or yet another gotcha in Sharepoint. I see the same behavior and have seen blog posts to this effect. My first thought was that it had to do with UTC vs local time. I've tried a variety of ISO 8601 formats for UTC and timezones, but in every case it seems to ignore the time component. The only workaround I can think of is to go ahead and return the whole set, then filter in whatever is consuming the data.
https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators
John Nunemaker has a blog post with some nice tips about Mongo ObjectIds -- http://mongotips.com/b/a-few-objectid-tricks/ -- in particular I was interested in the tip about generation_time. He suggests it's not necessary to explicitly store the created_at time in mongo documents because you can always pull it from the ID, which caught my attention. Problem is I can't figure out how to generate mongo queries in mongomapper to find documents based on creation time if all I have is the id.
If I store a key :created_at as part of the document I can do a query in mongomapper to get all documents created since Dec 1st like this:
Foo.where(:created_at.gt=>Time.parse("2011-12-01"))
(which maps to:
{created_at: {"$gt"=>Thu Dec 01 06:00:00 UTC 2011}}
I can't figure out how to make the equivalent query using the ObjectId.. I imagine it'd look something like this (though obviously generation_time is a ruby function, but is there an equivalent I can use on the objectid in the context of a mongo query?)
Foo.where('$where'=>"this.id.generation_time > new Date('2011-12-01')")
{$where: "this.id.generation_time > new Date('2011-12-01')"}
One further question: if I forgo storing separate timestamps, will I lose the timestamp metadata if I dump and restore my database using mongodump? Are there recommended backup/restore techniques that preserve ObjectIds?
this is javascript code which would be run in the shell but generation time is a mongomapper method so it doesn't make sense in the code you have.
In rails you would get the id by saying something like
created_at = self.id.generation_time.in_time_zone(Time.zone)
Where self refers to an instance of Foo.
And you would query by saying
Foo.find('_id' => {'$gte' => BSON::ObjectId.from_time(created_at)}).count
Why bother though... the hassle isn't worth it, just store the time.
Regarding the backup/restore techniques, unless you are manually reading and re-inserting mongodump/restore and similar tools will preserve the object id so you have nothing to worry about there.
I have been trying to find the answer to this for several hours... what timezone does the Magento API use? I am assuming that the Magento API returns all date values as GMT time because they do not append the timezone string at the end of the data. Is this correct?
I am wanting to use filters and want to make sure that the dates are being correctly interpreted in my offsite client.
From my experience, all dates in Magento seem to be stored in GMT. You should be able to confirm this trivially in any particular case by adding a record at a known time and calculating the offset.
I have a s3 bucket containing about 300gb of log files in no particular order.
I want to partition this data for use in hadoop-hive using a date-time stamp so that log-lines related to a particular day are clumped together in the same s3 'folder'. For example log entries for January 1st would be in files matching the following naming:
s3://bucket1/partitions/created_date=2010-01-01/file1
s3://bucket1/partitions/created_date=2010-01-01/file2
s3://bucket1/partitions/created_date=2010-01-01/file3
etc
What would be the best way for me to transform the data? Am I best just running a single script that reads in each file at a time and outputs data to the right s3 location?
I'm sure there's a good way to do this using hadoop, could someone tell me what that is?
What I've tried:
I tried using hadoop-streaming by passing in a mapper that collected all log entries for each date then wrote those directly to S3, returning nothing for the reducer, but that seemed to create duplicates. (using the above example, I ended up with 2.5 million entries for Jan 1st instead of 1.4million)
Does anyone have any ideas how best to approach this?
If Hadoop has free slots in the task tracker, it will run multiple copies of the same task. If your output format doesn't properly ignore the resulting duplicate output keys and values (which is possibly the case for S3; I've never used it), you should turn off speculative execution. If your job is map-only, set mapred.map.tasks.speculative.execution to false. If you have a reducer, set mapred.reduce.tasks.speculative.execution to false. Check out Hadoop: The Definitive Guide for more information.
Why not create an external table over this data, then use hive to create the new table?
create table partitioned (some_field string, timestamp string, created_date date) partition(created_date);
insert overwrite partitioned partition(created_date) as select some_field, timestamp, date(timestamp) from orig_external_table;
In fact, I haven't looked up the syntax, so you may need to correct it with reference to https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DML#LanguageManualDML-InsertingdataintoHiveTablesfromqueries.