[MAGNOLIA-2969] Enhance magnolia propertiesImportExporter to handle Dates, and to export to a properties file Created: 12/Dec/09  Updated: 04/Nov/15  Resolved: 04/Nov/15

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 4.2.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Ryan Gardner Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: import, unittests
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File enhancePropertyExporting2.patch     Text File propertiesExporting3.patch    
Issue Links:
dependency
is depended upon by MAGNOLIA-2970 Allow dumping of JCR nodes (from any ... Closed
Template:
Patch included:
Yes
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Testcase included:
Yes
Date of First Response:

 Description   

In my opinion, one of the biggest hassles in creating a unit test for something that is driven by data in a repository is creating the properties file to drive the test.

There was a mostly-implemented properties exporter in core but it didn't support writing out the data in the same format that it reads it in (namely, it didn't write the @uuid information or the @type information that it supports when importing from a properties file)

This patch enhances the importer / exporter to the point where you can dump out content to a Properties or to a string representation of the properties.

In addition, the Date nodes weren't dumped properly before. I added in some basic support for dumping and retrieving the Calendar objects from the properties file.

I think that this, combined with another patch I'm about to submit that adds a "dump to properties format" to the JCR Queries page in Admin Interface should greatly reduce the pain for creating unit tests that operate using data from a repository.



 Comments   
Comment by Ryan Gardner [ 15/Dec/09 ]

This updated version supports filtering with a contentfilter and uses the same dateformat used in the JCR.

Comment by Ryan Gardner [ 21/Dec/09 ]

This version adds support for exporting metadata and cleans up the previous export slightly.

Comment by Ryan Gardner [ 21/Dec/09 ]

In the latest, it's using a Jackrabbit ISO8061 util class to do the date exporting. I did try using Magnolia's DateUtils, but it requires a valid Locale it seems to work so I switched back to this ISO8061 class because it works and doesn't require a Locale. DateUtils could probably have a new method added that would do the same function (heck, and because of the license of the Jackrabbit, you could probably just copypasta their util class into it and put a note in your source saying that's where it's from)

This version makes some of the content filter selection in the related patch a bit irrelevant since it will always export the metadata nodes if they are there (the developer can just delete them if he doesn't want them in his test properties).

I've already used this a few times to generate test data from both the config and data repositories and it works nicely.

Comment by Magnolia International [ 20/Jan/10 ]

Patch applied - minor style corrections. I also removed the support for importing any type (and the corresponding that checked URLs could be imported), since they are not supported jcr property types. Let me know if I'm missing something.

Now, one thing I want to do before applying MAGNOLIA-2970 and letting this go in the wild, is revise the API. The API previous to this patch was already a half-baked thing; it should either be all static, or not. (import methods were non-static, exports were static).

I'd also like to see if we can remove/simplify the duplication of code wrt type conversions (I don't think all the convert*ToExportString methods are necessary)

But thanks, great stuff anyhow !

Comment by Magnolia International [ 12/Mar/10 ]

Pushing this to the next version, sorry.

Comment by Michael Mühlebach [ 04/Nov/15 ]

Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes.
Thanks for taking the time to raise this issue. As you are no doubt aware this issue has been on our backlog for some time now with very little movement.
I'm going to close this to set expectations so the issue doesn't stay open for years with few updates. If the issue is still relevant please feel free to reopen it or create a new issue.

Generated at Mon Feb 12 03:41:54 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.