Ben, Yes, it was not discussed since you were missing and we wanted you to be part of the decision... also time was short and it seemed like a decision on the list could be reached.
Yes, I can confirm that it doesn't work, if we've built the module using 1.9.0-RC3 and then say require version to be 1.8.1 and have the LocationAttributeResource that uses the LocationAttribute class. Spring doesn't like it and throws the following exception: http://pastebin.com/GBy9bRyW I think resource versioning is fairly trivial. If the resource changes in its representation (or params it takes), we should make it v2 (or v1.1) and then only that resource has a v2 in its URL while others have v1. This is how many services exist where resources have different versions in the same release. --- Regards, Saptarshi PURKAYASTHA My Tech Blog: http://sunnytalkstech.blogspot.com You Live by CHOICE, Not by CHANCE On 17 May 2012 03:35, Ben Wolfe <b...@openmrs.org> wrote: > I don't see this in the notes for the design call today, so I assume it > wasn't discussed. > http://notes.openmrs.org/Design-Forum-2012-05-16 > > I do NOT want branches for the module. I also would prefer to not have > the -ext modules. Can someone confirm that the rest module def does not > start up if the provider classes are just on the path? If it fails, I > assume it is because of classpath scanning by us or by spring. The former > could be caught and handled gracefully. > > Adding a v2 of a resource would come at any point, I think. I don't the > the v1/v2/v3 versions match the rest module version which doesn't match the > openmrs version. (We will need to document each rest method and keep it > updated on the wiki to make alleviate developer version matchings) > > Ben > > > On Wed, May 16, 2012 at 5:59 PM, Darius Jazayeri > <djazayeri+...@gmail.com>wrote: > >> Yes, my suggestion is that we'll have to manage up to a couple of -ext >> modules, for supported versions of OpenMRS. At some (way future) point we >> might decide to stop supporting 1.8 in active web service development, and >> we could fold -19ext into the main webservice module, and increase the >> required version to 1.9. >> >> I think Ben prefers to branch the module instead (so we'd have a >> 1.8-compatible branch, a 1.9-compatible branch, etc). >> >> Let's discuss this (in a time-boxed way!) on the design call today, as >> neither Ben or I are experts on this. >> >> Another question: what happens when we introduce an incompatible >> variation of a resource (e.g. in 1.9 concept.mappings changes >> significantly)? Would we make that v2 of the concept resource only? Or does >> introducing v2 imply incrementing the version of the whole API? (And thus >> we might try to hide the new concept map structure under the hood.) >> >> -Darius >> >> >> On Wed, May 16, 2012 at 7:41 AM, Saptarshi Purkayastha >> <sun...@gmail.com>wrote: >> >>> So is the plan that with every new data model change in the core, there >>> will another web service extension module?? >>> That means to get web services in 1.10, I'd have to install the >>> webservices.rest, the webservices.rest-19ext and then >>> webservices.rest-110ext (or the new webservices-110.ozip) >>> >>> So, Spencer Kathol's work on the Provider should be in the >>> webservices.rest-19ext module and not in 1.1 >>> >>> --- >>> Regards, >>> Saptarshi PURKAYASTHA >>> >>> My Tech Blog: http://sunnytalkstech.blogspot.com >>> You Live by CHOICE, Not by CHANCE >>> >>> >>> On 16 May 2012 19:55, Darius Jazayeri <djazayeri+...@gmail.com> wrote: >>> >>>> Saptarshi, >>>> >>>> I think that for the foreseeable future, all versions of the restws >>>> module (1.0, 1.1, 1.2, etc) will require OpenMRS 1.8.1. >>>> >>>> So, webservices.rest 1.1 will still require OpenMRS 1.8.1. In addition >>>> we'll have a webservices.rest-19ext that requires 1.9 and provides the >>>> additional 1.9 resources. >>>> >>>> Roger, >>>> >>>> I actually think there's a benefit to having our REST API change more >>>> slowly than our java API. (It would be wonderful to be able to build a >>>> future version of sync based on having 1.8, 1.9, and 1.10 children all >>>> synching over web services.) >>>> >>>> -Darius >>>> >>>> >>>> >>>> On Wed, May 16, 2012 at 4:58 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR) < >>>> r...@cdc.gov> wrote: >>>> >>>>> On further review, it seems to me that while there are certain types >>>>> of changes to the data model that can be made without breaking RESTWS, >>>>> others cannot. For example, adding a new nullable field to a table >>>>> requires a change to the creatable and updatable field lists and to the >>>>> could-be-missing field list within the resource (as well as corresponding >>>>> changes in the .hbm and pojo), but existing calls to the resource will >>>>> still work correctly, so it doesn't break anything. But adding providers >>>>> and using them as a mapped collection in encounters instead of a user >>>>> reference does break things, you can no longer create an encounter with a >>>>> user.**** >>>>> >>>>> ** ** >>>>> >>>>> I am beginning to think that we should roll RESTWS into core so that >>>>> it moves with its version-appropriate data model. So 1.9.1 should include >>>>> a RESTWS appropriate to its data model. That would leave the "v1.0" >>>>> portion of the URL to handle changes in the semantics of the calls, should >>>>> that ever happen. And 1.8 would be the only version to use the RESTWS >>>>> module (or we could roll it into 1.8.4 or whatever is next).**** >>>>> >>>>> ** ** >>>>> >>>>> *From:* dev@openmrs.org [mailto:dev@openmrs.org] *On Behalf Of *Darius >>>>> Jazayeri >>>>> *Sent:* Tuesday, May 15, 2012 7:57 PM >>>>> *To:* openmrs-deve...@listserv.iupui.edu >>>>> *Subject:* Re: [OPENMRS-DEV] RESTWS release timing/content**** >>>>> >>>>> ** ** >>>>> >>>>> Roger,**** >>>>> >>>>> ** ** >>>>> >>>>> To clarify, I do *not* think we should have branches of the >>>>> webservices.rest module for OpenMRS 1.8.x, 1.9.x, 1.10.x, etc. I assume >>>>> that we will release webservices.rest v1.0, and this will work with >>>>> OpenMRS >>>>> 1.8.2+. However if you're using OpenMRS 1.9 with webservices.rest v1.0 you >>>>> will not have access to anything that wasn't available in OpenMRS 1.8 >>>>> (e.g. >>>>> Visits, Location Attributes) I think we should do a >>>>> "webservices.rest-19ext" module that adds support for all the new 1.9 >>>>> features.**** >>>>> >>>>> ** ** >>>>> >>>>> My initial thought is that adding new fields to existing resources >>>>> (e.g. adding attributes to Location) should not increment the version >>>>> number of the REST API. (But this is not well-thought out.)**** >>>>> >>>>> ** ** >>>>> >>>>> Regarding whether to release 1.0 or not. I feel very strongly that we >>>>> should release 1.0 ASAP, with the current functionality.**** >>>>> >>>>> ** ** >>>>> >>>>> Almost a year ago we set out a limited set of functional requirements: >>>>> we wanted to satisfy a few key user stories that were suggested by >>>>> interested people. (See this wiki >>>>> page<https://wiki.openmrs.org/x/94IHAQ>.) >>>>> We added to that the strategic requirement that whatever we release as >>>>> "1.0" should be an API that we want to support going forwards.**** >>>>> >>>>> ** ** >>>>> >>>>> As a result of that requirement we delayed doing a 1.0 release to make >>>>> some fundamental design changes. (The bulk of these were spurred by you, >>>>> Roger, because you insisted we deal with the issue of subclasses. I think >>>>> you were absolutely right to do that, and I think it led to us doing some >>>>> very-necessary refactoring of the code. So, a non-sarcastic "Thanks" for >>>>> that.)**** >>>>> >>>>> ** ** >>>>> >>>>> At this point I really think we need release our current code (just >>>>> missing a couple of reviews) as 1.0, and commit to supporting it. Work can >>>>> and should continue to happen on the module. It is straightforward to add >>>>> some missing resources and release 1.1, 1.2, etc. (For the record those >>>>> would be *module* versions, *not* API versions.)**** >>>>> >>>>> ** ** >>>>> >>>>> -Darius**** >>>>> >>>>> ** ** >>>>> >>>>> PS- Regarding competition of resources between finishing off the 1.8 >>>>> API and doing the 1.9 API...I'd say "patches are welcome". Whatever >>>>> tickets >>>>> people create and vote on, and whatever tickets people claim and submit >>>>> patches to, is what will get released first. :-)**** >>>>> >>>>> ** ** >>>>> >>>>> On Tue, May 15, 2012 at 3:21 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) < >>>>> r...@cdc.gov> wrote:**** >>>>> >>>>> We have not had an up-to-date version of RESTWS in the module >>>>> repo for quite a while, and there have been a lot of important changes. >>>>> Darius would like to get something into the repo, and I agree, but I don't >>>>> think the current version is sufficiently complete and correct to just >>>>> move >>>>> on. I have four reasons for this: (1) we don't have all the 1.8 data >>>>> model >>>>> in REST; (2) we have some known anomalies to fix; (3) we haven't had much >>>>> experience with the subclass model; and (4) there will be a competition >>>>> for >>>>> resources due to the need for a version that supports the 1.9 data model. >>>>> **** >>>>> >>>>> **** >>>>> >>>>> If I understand Darius correctly, he never thought version 1.0 >>>>> would be a complete exposure of the data model, but only a sufficient >>>>> proof >>>>> of concept to assure that the interface would not change drastically. But >>>>> I believe everyone who has tried to use RESTWS has found a data object >>>>> they >>>>> needed which was not exposed. If a needed object is not exposed, then the >>>>> user can't really put RESTWS to the test. I don't really care what the >>>>> 1.8-compatible and the 1.9-compatible releases are called, I just want a >>>>> clear path to a fully capable 1.8-compatible version. I don't want issues >>>>> (1)-(3) to be lost as we pursue 1.9.**** >>>>> >>>>> **** >>>>> >>>>> It is not clear how we are going to revise RESTWS as the data >>>>> model changes. If I understand Darius correctly, the "v1.0" portion of >>>>> the >>>>> URL will indicate that the module supports 1.8, and will be changed to >>>>> another value (most likely "v2.0") when the module supports 1.9. There >>>>> will probably not be much backporting (maybe additional queries or custom >>>>> reps or a resource-specific catalog call) because most of the changes will >>>>> depend on the data model (in the case of 1.8-1.9, location attributes, >>>>> providers, provider attributes, visits, multiple providers per encounter, >>>>> concept mapping, complex concepts). It seems to make sense to make a new >>>>> 2.0 head and keep a 1.0 branch, but I don't think we've ever worked on >>>>> both >>>>> a branch and the head at the same time. So I think it would be better to >>>>> get 1.0 to a more complete, correct state before we start work on 2.0. >>>>> **** >>>>> >>>>> **** >>>>> >>>>> Maybe the sprint schedule needs to be revised to have an RESTWS >>>>> 1.1 (or whatever) sprint sooner, and tickets that address 1.9 issues >>>>> should >>>>> be given a new future release fix 2.0 (or whatever). Maybe we can have >>>>> simultaneous 1.1 and 2.0 sprints.**** >>>>> >>>>> **** >>>>> >>>>> **** >>>>> >>>>> **** >>>>> ------------------------------ >>>>> >>>>> Click here to >>>>> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from >>>>> OpenMRS Developers' mailing list >>>>> **** >>>>> >>>>> ** ** >>>>> ------------------------------ >>>>> >>>>> Click here to >>>>> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from >>>>> OpenMRS Developers' mailing list >>>>> **** >>>>> ------------------------------ >>>>> Click here to >>>>> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from >>>>> OpenMRS Developers' mailing list >>>>> >>>> >>>> >>> ------------------------------ >>> Click here to >>> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >>> >> >> ------------------------------ >> Click here to >> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> > > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l]