Skip to content
This repository has been archived by the owner on Nov 9, 2022. It is now read-only.

Fix #551: Only load content that is newer locally than on the server #552

Merged
merged 8 commits into from
Feb 5, 2016

Conversation

nespera
Copy link

@nespera nespera commented Nov 6, 2015

#551

This change adds support for a command line flag that causes "deploy content" to compare modification times on local files and timestamps on deployed documents. It then only deploys files which are new or have newer modification dates locally.

The use case is the situation where the deployed files are a "baseline" set that could potentially change in a running system.

It's not optimized for speed and will be slow if there's a large number of small files, as an individual timestamp query is done for each.

files.select { |file_uri|
target_uri = xcc.build_target_uri(file_uri, options)

q = %Q{"" || xdmp:timestamp-to-wallclock(xdmp:document-timestamp("#{target_uri}"))}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting, leverages xdmp:document-timestamp! Won't work on ML5, but does on 6+.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I should add some error handling so it will not break on ML5?

@nespera
Copy link
Author

nespera commented Nov 13, 2015

I have now changed it so that it will:

  • give an error if you try to filter before ML6
  • hit ML once to determine all the timestamps

I thought it could be an issue if you have an enormous list of files, but I simulated the XQuery call in qconsole and it was happy checking 10000 document timestamps at once.

uris_as_string = uris.map{|i| "\"#{i}\""}.join(",")
q = %Q{for $u in (#{uris_as_string}) return "" || xdmp:timestamp-to-wallclock(xdmp:document-timestamp($u))}

result = execute_query q, :db_name => @properties["ml.content-db"]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your query is running against the content database. I didn't get any timestamps back until I changed this to ["ml.modules-db"].

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function is looking at timestamps on documents in the content database, so isn't that the correct database to be running against?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this being used to deploy content (data) or modules (code)? If you're deploying modules, they are sent to the modules database, so you'll need to check the timestamps there.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is only used for "deploy content"

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, my mistake.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this feature would be very much appreciated for deploy modules as well, at the least. For that it would be useful if it would be more dynamic..

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could potentially pass in the database name to get_db_timestamps, but it seems like unneeded flexibility at this point. Having incremental deployment of modules doesn't seem useful to me so I will leave that (and making get_db_timestamps more flexible) to someone else.

dmcassel added a commit that referenced this pull request Feb 5, 2016
Fix #551: Only load content that is newer locally than on the server
@dmcassel dmcassel merged commit d10c6c7 into marklogic-community:dev Feb 5, 2016
@dmcassel
Copy link
Collaborator

dmcassel commented Feb 5, 2016

Looks like what was identified previously has been fixed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants