Re: short term branch for project/group keys
Jesse and myself had a chat yesterday morning about the key-refactoring branch that we spun before Christmas last year, and we reckon that it might be an idea to get 1.1-alpha rolling and meantime gather more thoughts around Groupings (introduce versions/tags). We think having String-based keys for groups might be more feasible for v1.2. However, we are keen to bring over the API changes where the 'int' Ids are now converted to 'long'. Some other bits like breaking up the existing Project and ProjectGroup interfaces can be continued on the trunk itself after the merge. What do others think? Cheers, Rahul - Original Message - From: Jesse McConnell [EMAIL PROTECTED] To: continuum-dev@maven.apache.org Sent: Friday, December 22, 2006 8:30 AM Subject: short term branch for project/group keys I am thinking about pulling a short term branch of continuum with rahul and working on getting everything converted to using a string based key project and project group reference in all apis and in all of the UI decision making items. He has tomorrow off so I think that unless anyone has any big issues with it we'll try and make that branch and work on it tomorrow. the end result of it would be: * int id's for project and project group in the model are for internal store usage * name's for project and project group are for presentation purposes only * key's are for all api usage and passing around un URL's etc. some quick benefits are: * consistency across all apis and url manipulations * ability to add quick url rewriting for direct linking of projects foo.org/Doxia/Core * common keys across running continuum instances for clustering jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: short term branch for project/group keys
I am loathe to let a branch lay around for a long time with minimal work being done actively on it and we learned what we wanted to from it in the short time we worked with it I think. my take-away was that the change the string based keys will be a good change but its large enough that it should be done in the context of some other refactoring and changes. as for the int-long id change, I think its a good thing and will focus us to address the database upgrading issue so its all good imo :) jesse On 1/16/07, Rahul Thakur [EMAIL PROTECTED] wrote: Jesse and myself had a chat yesterday morning about the key-refactoring branch that we spun before Christmas last year, and we reckon that it might be an idea to get 1.1-alpha rolling and meantime gather more thoughts around Groupings (introduce versions/tags). We think having String-based keys for groups might be more feasible for v1.2. However, we are keen to bring over the API changes where the 'int' Ids are now converted to 'long'. Some other bits like breaking up the existing Project and ProjectGroup interfaces can be continued on the trunk itself after the merge. What do others think? Cheers, Rahul - Original Message - From: Jesse McConnell [EMAIL PROTECTED] To: continuum-dev@maven.apache.org Sent: Friday, December 22, 2006 8:30 AM Subject: short term branch for project/group keys I am thinking about pulling a short term branch of continuum with rahul and working on getting everything converted to using a string based key project and project group reference in all apis and in all of the UI decision making items. He has tomorrow off so I think that unless anyone has any big issues with it we'll try and make that branch and work on it tomorrow. the end result of it would be: * int id's for project and project group in the model are for internal store usage * name's for project and project group are for presentation purposes only * key's are for all api usage and passing around un URL's etc. some quick benefits are: * consistency across all apis and url manipulations * ability to add quick url rewriting for direct linking of projects foo.org/Doxia/Core * common keys across running continuum instances for clustering jesse -- jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: short term branch for project/group keys
On 27/12/2006, at 7:10 PM, Rahul Thakur wrote: Updates to any children hanging off key entities should cascade. This makes sense if and only if the children are dependent. So, for build definitions - that's right. Profiles and such are all 'links' and so will be managed by the normal foreign key construct. Thanks Brett! I might need some help with Jpox when I hit this scenario. It would be nice to have some sort of 'lazy' intialization to happen when children hanging off key entities are retrieved, but not sure yet what Jpox offers (fetch groups?). Cheers, Rahul
Re: short term branch for project/group keys
Yes, it's fetch groups. The store (pre-groups) took all this into account, however the lack of central management for some of it caused it to be pretty error prone. Those problems were related to Continuum's design, not anything to do with the use of JPOX (and something that'd be encountered in iBatis, or JPA, or anything else we used). On 28/12/2006, at 7:33 PM, Rahul Thakur wrote: On 27/12/2006, at 7:10 PM, Rahul Thakur wrote: Updates to any children hanging off key entities should cascade. This makes sense if and only if the children are dependent. So, for build definitions - that's right. Profiles and such are all 'links' and so will be managed by the normal foreign key construct. Thanks Brett! I might need some help with Jpox when I hit this scenario. It would be nice to have some sort of 'lazy' intialization to happen when children hanging off key entities are retrieved, but not sure yet what Jpox offers (fetch groups?). Cheers, Rahul
Re: short term branch for project/group keys
On 22 Dec 06, at 11:48 AM 22 Dec 06, Jesse McConnell wrote: nope, no fundamental reasons behind the immutable bit on the keys, I am cool with them being open for editing. I think they are immutable so when links are created with them they don't just disappear. Jason. jesse On 12/22/06, Christian Edward Gruber [EMAIL PROTECTED] wrote: This all sounds great, but why do they need to be immutable? If they are essentially used for lookups, and they only exist in one place in the database (because it's normalized enough through surrogate keys), then other then the obvious caveats about external things depending on the keys, why couldn't these string keys change? There should be no referential integrity issues, because these keys are not the subjects of any joins - just where clauses from the interfaces. This would include project.key, group.key, buildDef.key, notifier.key, etc. It could even apply to userId, though standard practice is that usernames are immutable. All the other lookup keys could quite easily be mutable/re-nameable if we wished. Am I missing something? I can certainly see the usefulness of being able to, for maintenance of the continuum instance. Not strictly necessary, but saves several steps. Christian. Jesse McConnell wrote: On 12/22/06, Brett Porter [EMAIL PROTECTED] wrote: Sounds good, as long as the store remains independent of them. I don't want to get into the situation like in JIRA where you can't rename a string key. Yes, jason pinged me on this since I guess I wasn't completely clear in that summary. the project.id and projectGroup.id will basically disappear from continuum, reserved strictly for the underlying store. The store can do whatever it wants with them. The UI will never pass around a projectId=26 param on a url making you wonder what the heck it was. A nice side effect of this IMO is that the #'s in the working directory would go away as well, defaulting instead to a nested directory structure of workingDirectory/GroupKey/ProjectKey/pom.xml Now I had honestly been thinking of making the key's immutable, since the names of the group's and project's are to be used for all presentational type things. I was going to treat keys under the same functional requirements that usernames generally have. Maybe we offer a 'Clone' option that makes a deep copy of the data in the DB into a new name and then allow the deletion of the old one... Anyway, here are the restrictions I thought of placing on the keys. * [a-zA-Z1-9.-:] for all keys * group key is unique * group key + project key is unique * project key should _not_ need to be unique (ex Doxia/Core + Maven/Core + Continuum/Core) * keys are immutable, set upon creation Before starting to hack on this, perhaps you could list out all the keys you think are needed, and some examples? I'm interested in how it relates to group IDs and artifact IDs in particular. Initially I was planning on doing just the project key and group key since there is so much involved with getting just those two in place. However everything would probably go that way so that Profiles, Schedules, BuildDefinitions, etc...anything with an int ID that is used around in continuum would be converted to use a strongly typed string key insteadthe ones other then project and group are less important in the short term since they are not a constant source of confusion...but eventually yes anything with and ID would get a Key like this. If the branch is a success and is voted back onto trunk then those could take place on trunk I think since they are smaller scope. As for how they would relate to groupId's and artifactId's it was not my intent to deal with those at all. One of the things that got us into the mess that currently exists was too great a focus on the m2 side of continuum. IMO the group and project keys should be kept external to any concept of project type. That way we can always maintain a clear delineation between a group and its member projects in relation to other groups. For instance, one of my goals here is to make it super easy to have multiple versions of Doxia load up in continuum and execute in their little sandboxes. Group Keys of Doxia and Doxia-Refactor (just an example branch) should be able to seamlessly import the doxia project from its relative sources and peacefully coexist. And it should be just as easy to do the same with a number of ant, shell and maven1 projects. Anyway, some foreseeable real world example keys in one continuum instance: Group: Maven-Trunk Projects: Core Api Artfiact Group: Maven-2.0.5 Projects: Core Api Artifact Group: Continuum Projects: Core Api Store Webapp cheers, jesse - Brett On 22/12/2006, at 6:30 AM, Jesse McConnell wrote: I am thinking about pulling a short term branch of continuum with rahul and
Re: short term branch for project/group keys
This all sounds great, but why do they need to be immutable? If they are essentially used for lookups, and they only exist in one place in the database (because it's normalized enough through surrogate keys), then other then the obvious caveats about external things depending on the keys, why couldn't these string keys change? There should be no referential integrity issues, because these keys are not the subjects of any joins - just where clauses from the interfaces. This would include project.key, group.key, buildDef.key, notifier.key, etc. It could even apply to userId, though standard practice is that usernames are immutable. All the other lookup keys could quite easily be mutable/re-nameable if we wished. Am I missing something? I can certainly see the usefulness of being able to, for maintenance of the continuum instance. Not strictly necessary, but saves several steps. Christian. Jesse McConnell wrote: On 12/22/06, Brett Porter [EMAIL PROTECTED] wrote: Sounds good, as long as the store remains independent of them. I don't want to get into the situation like in JIRA where you can't rename a string key. Yes, jason pinged me on this since I guess I wasn't completely clear in that summary. the project.id and projectGroup.id will basically disappear from continuum, reserved strictly for the underlying store. The store can do whatever it wants with them. The UI will never pass around a projectId=26 param on a url making you wonder what the heck it was. A nice side effect of this IMO is that the #'s in the working directory would go away as well, defaulting instead to a nested directory structure of workingDirectory/GroupKey/ProjectKey/pom.xml Now I had honestly been thinking of making the key's immutable, since the names of the group's and project's are to be used for all presentational type things. I was going to treat keys under the same functional requirements that usernames generally have. Maybe we offer a 'Clone' option that makes a deep copy of the data in the DB into a new name and then allow the deletion of the old one... Anyway, here are the restrictions I thought of placing on the keys. * [a-zA-Z1-9.-:] for all keys * group key is unique * group key + project key is unique * project key should _not_ need to be unique (ex Doxia/Core + Maven/Core + Continuum/Core) * keys are immutable, set upon creation Before starting to hack on this, perhaps you could list out all the keys you think are needed, and some examples? I'm interested in how it relates to group IDs and artifact IDs in particular. Initially I was planning on doing just the project key and group key since there is so much involved with getting just those two in place. However everything would probably go that way so that Profiles, Schedules, BuildDefinitions, etc...anything with an int ID that is used around in continuum would be converted to use a strongly typed string key insteadthe ones other then project and group are less important in the short term since they are not a constant source of confusion...but eventually yes anything with and ID would get a Key like this. If the branch is a success and is voted back onto trunk then those could take place on trunk I think since they are smaller scope. As for how they would relate to groupId's and artifactId's it was not my intent to deal with those at all. One of the things that got us into the mess that currently exists was too great a focus on the m2 side of continuum. IMO the group and project keys should be kept external to any concept of project type. That way we can always maintain a clear delineation between a group and its member projects in relation to other groups. For instance, one of my goals here is to make it super easy to have multiple versions of Doxia load up in continuum and execute in their little sandboxes. Group Keys of Doxia and Doxia-Refactor (just an example branch) should be able to seamlessly import the doxia project from its relative sources and peacefully coexist. And it should be just as easy to do the same with a number of ant, shell and maven1 projects. Anyway, some foreseeable real world example keys in one continuum instance: Group: Maven-Trunk Projects: Core Api Artfiact Group: Maven-2.0.5 Projects: Core Api Artifact Group: Continuum Projects: Core Api Store Webapp cheers, jesse - Brett On 22/12/2006, at 6:30 AM, Jesse McConnell wrote: I am thinking about pulling a short term branch of continuum with rahul and working on getting everything converted to using a string based key project and project group reference in all apis and in all of the UI decision making items. He has tomorrow off so I think that unless anyone has any big issues with it we'll try and make that branch and work on it tomorrow. the end result of it would be: * int id's for project and project group in the model are for internal
Re: short term branch for project/group keys
nope, no fundamental reasons behind the immutable bit on the keys, I am cool with them being open for editing. jesse On 12/22/06, Christian Edward Gruber [EMAIL PROTECTED] wrote: This all sounds great, but why do they need to be immutable? If they are essentially used for lookups, and they only exist in one place in the database (because it's normalized enough through surrogate keys), then other then the obvious caveats about external things depending on the keys, why couldn't these string keys change? There should be no referential integrity issues, because these keys are not the subjects of any joins - just where clauses from the interfaces. This would include project.key, group.key, buildDef.key, notifier.key, etc. It could even apply to userId, though standard practice is that usernames are immutable. All the other lookup keys could quite easily be mutable/re-nameable if we wished. Am I missing something? I can certainly see the usefulness of being able to, for maintenance of the continuum instance. Not strictly necessary, but saves several steps. Christian. Jesse McConnell wrote: On 12/22/06, Brett Porter [EMAIL PROTECTED] wrote: Sounds good, as long as the store remains independent of them. I don't want to get into the situation like in JIRA where you can't rename a string key. Yes, jason pinged me on this since I guess I wasn't completely clear in that summary. the project.id and projectGroup.id will basically disappear from continuum, reserved strictly for the underlying store. The store can do whatever it wants with them. The UI will never pass around a projectId=26 param on a url making you wonder what the heck it was. A nice side effect of this IMO is that the #'s in the working directory would go away as well, defaulting instead to a nested directory structure of workingDirectory/GroupKey/ProjectKey/pom.xml Now I had honestly been thinking of making the key's immutable, since the names of the group's and project's are to be used for all presentational type things. I was going to treat keys under the same functional requirements that usernames generally have. Maybe we offer a 'Clone' option that makes a deep copy of the data in the DB into a new name and then allow the deletion of the old one... Anyway, here are the restrictions I thought of placing on the keys. * [a-zA-Z1-9.-:] for all keys * group key is unique * group key + project key is unique * project key should _not_ need to be unique (ex Doxia/Core + Maven/Core + Continuum/Core) * keys are immutable, set upon creation Before starting to hack on this, perhaps you could list out all the keys you think are needed, and some examples? I'm interested in how it relates to group IDs and artifact IDs in particular. Initially I was planning on doing just the project key and group key since there is so much involved with getting just those two in place. However everything would probably go that way so that Profiles, Schedules, BuildDefinitions, etc...anything with an int ID that is used around in continuum would be converted to use a strongly typed string key insteadthe ones other then project and group are less important in the short term since they are not a constant source of confusion...but eventually yes anything with and ID would get a Key like this. If the branch is a success and is voted back onto trunk then those could take place on trunk I think since they are smaller scope. As for how they would relate to groupId's and artifactId's it was not my intent to deal with those at all. One of the things that got us into the mess that currently exists was too great a focus on the m2 side of continuum. IMO the group and project keys should be kept external to any concept of project type. That way we can always maintain a clear delineation between a group and its member projects in relation to other groups. For instance, one of my goals here is to make it super easy to have multiple versions of Doxia load up in continuum and execute in their little sandboxes. Group Keys of Doxia and Doxia-Refactor (just an example branch) should be able to seamlessly import the doxia project from its relative sources and peacefully coexist. And it should be just as easy to do the same with a number of ant, shell and maven1 projects. Anyway, some foreseeable real world example keys in one continuum instance: Group: Maven-Trunk Projects: Core Api Artfiact Group: Maven-2.0.5 Projects: Core Api Artifact Group: Continuum Projects: Core Api Store Webapp cheers, jesse - Brett On 22/12/2006, at 6:30 AM, Jesse McConnell wrote: I am thinking about pulling a short term branch of continuum with rahul and working on getting everything converted to using a string based key project and project group reference in all apis and in all of the UI decision making items. He has tomorrow off so I think that unless anyone has any big
Re: short term branch for project/group keys
project keys are not unique, you need the group key and project key together to get the actual summary. it should be fine in the store since the index is the uniqifying bit..the project class will need a group key in it as well to make that work a couple of other things came up today so I haven't started that branch yet but hopefully soon as I clear off a couple of things now. jesse On 12/22/06, Rahul Thakur [EMAIL PROTECTED] wrote: So, if we have 2 sessions using the same project as target - user A opens up some Project X's summary for viewing - user B updates Project X's string key to Y. Wouldn't that invalidate the key values being used by user A's session? How will this be handled? Cheers, Rahul - Original Message - From: Jesse McConnell [EMAIL PROTECTED] To: continuum-dev@maven.apache.org Sent: Saturday, December 23, 2006 6:48 AM Subject: Re: short term branch for project/group keys nope, no fundamental reasons behind the immutable bit on the keys, I am cool with them being open for editing. jesse On 12/22/06, Christian Edward Gruber [EMAIL PROTECTED] wrote: This all sounds great, but why do they need to be immutable? If they are essentially used for lookups, and they only exist in one place in the database (because it's normalized enough through surrogate keys), then other then the obvious caveats about external things depending on the keys, why couldn't these string keys change? There should be no referential integrity issues, because these keys are not the subjects of any joins - just where clauses from the interfaces. This would include project.key, group.key, buildDef.key, notifier.key, etc. It could even apply to userId, though standard practice is that usernames are immutable. All the other lookup keys could quite easily be mutable/re-nameable if we wished. Am I missing something? I can certainly see the usefulness of being able to, for maintenance of the continuum instance. Not strictly necessary, but saves several steps. Christian. Jesse McConnell wrote: On 12/22/06, Brett Porter [EMAIL PROTECTED] wrote: Sounds good, as long as the store remains independent of them. I don't want to get into the situation like in JIRA where you can't rename a string key. Yes, jason pinged me on this since I guess I wasn't completely clear in that summary. the project.id and projectGroup.id will basically disappear from continuum, reserved strictly for the underlying store. The store can do whatever it wants with them. The UI will never pass around a projectId=26 param on a url making you wonder what the heck it was. A nice side effect of this IMO is that the #'s in the working directory would go away as well, defaulting instead to a nested directory structure of workingDirectory/GroupKey/ProjectKey/pom.xml Now I had honestly been thinking of making the key's immutable, since the names of the group's and project's are to be used for all presentational type things. I was going to treat keys under the same functional requirements that usernames generally have. Maybe we offer a 'Clone' option that makes a deep copy of the data in the DB into a new name and then allow the deletion of the old one... Anyway, here are the restrictions I thought of placing on the keys. * [a-zA-Z1-9.-:] for all keys * group key is unique * group key + project key is unique * project key should _not_ need to be unique (ex Doxia/Core + Maven/Core + Continuum/Core) * keys are immutable, set upon creation Before starting to hack on this, perhaps you could list out all the keys you think are needed, and some examples? I'm interested in how it relates to group IDs and artifact IDs in particular. Initially I was planning on doing just the project key and group key since there is so much involved with getting just those two in place. However everything would probably go that way so that Profiles, Schedules, BuildDefinitions, etc...anything with an int ID that is used around in continuum would be converted to use a strongly typed string key insteadthe ones other then project and group are less important in the short term since they are not a constant source of confusion...but eventually yes anything with and ID would get a Key like this. If the branch is a success and is voted back onto trunk then those could take place on trunk I think since they are smaller scope. As for how they would relate to groupId's and artifactId's it was not my intent to deal with those at all. One of the things that got us into the mess that currently exists was too great a focus on the m2 side of continuum. IMO the group and project keys should be kept external to any concept of project type. That way we can always maintain a clear delineation between a group and its member projects in relation to other groups. For instance, one of my goals here is to make
Re: short term branch for project/group keys
On 23/12/2006, at 12:24 AM, Jesse McConnell wrote: the project.id and projectGroup.id will basically disappear from continuum, reserved strictly for the underlying store. The store can do whatever it wants with them. Ok, so a project(Group)? will have: id : int key : String name : String ... Where key is used as a reference, id is used as a datastore/model identity, and name is used as a display. Sounds good. We could then have a table of old names: id : int oldKey : String These could be used so that failed lookup on a key could then look in the old key's to find out what the new one is (like when you move an issue in JIRA). I'm not sure this is needed initially - only if we support picking up renames to the project itself. I suggest that a project should, by default, use the Maven group ID and artifact Id as the group key and project key respectively. Obviously, for Ant/Shell/etc, this will need to be entered by hand. The UI will never pass around a projectId=26 param on a url making you wonder what the heck it was. A nice side effect of this IMO is that the #'s in the working directory would go away as well, defaulting instead to a nested directory structure of workingDirectory/GroupKey/ProjectKey/pom.xml Cool. We could also do nice things with the URLs using a WW mapper: /continuum/org.apache.maven/maven-project/buildHistory Anyway, here are the restrictions I thought of placing on the keys. * [a-zA-Z1-9.-:] for all keys * group key is unique * group key + project key is unique * project key should _not_ need to be unique (ex Doxia/Core + Maven/Core + Continuum/Core) * keys are immutable, set upon creation For now sounds good (would like to review immutability later), though suggest using Maven IDs where possible. Initially I was planning on doing just the project key and group key since there is so much involved with getting just those two in place. However everything would probably go that way so that Profiles, Schedules, BuildDefinitions, etc...anything with an int ID that is used around in continuum would be converted to use a strongly typed string key insteadthe ones other then project and group are less important in the short term since they are not a constant source of confusion...but eventually yes anything with and ID would get a Key like this. If the branch is a success and is voted back onto trunk then those could take place on trunk I think since they are smaller scope. Sounds good. I'm not sure how often you really need to reference a schedule or build definition (or how you'd really appropriately describe them). We don't want to go to the point where you have to make up extra information that is not useful. As for how they would relate to groupId's and artifactId's it was not my intent to deal with those at all. One of the things that got us into the mess that currently exists was too great a focus on the m2 side of continuum. IMO the group and project keys should be kept external to any concept of project type. That way we can always maintain a clear delineation between a group and its member projects in relation to other groups. For instance, one of my goals here is to make it super easy to have multiple versions of Doxia load up in continuum and execute in their little sandboxes. Whoa. Repeat the mantra - convention over configuration :) One of the great strengths of Continuum is that it takes its defaults from Maven. Sure, they can be changeable, but they *must* be the default. That's not a mess. As for multiple branches - I'm not convinced either way yet. I Can see the merits in your example of simply making them new projects, but then they need to be reconfigured (often in the same way). On the other hand, it could be that branches should be a subsection of the project, not an additional project. The hierachy would be group project branch/instance. Notifiers and build definitions would be attached to the group or the project, and can be excluded from a given branch/instance if not used there. Let's discuss that separately as it's obviously new functionality, whereas loading them up as new projects is a workable current solution. If we take the defaults, all that means is that adding a second one should complain, and you need to edit the key. No big deal. - Brett
Re: short term branch for project/group keys
If we use JPA or some such with caching at the HttpSession-scoped level for keys (with some fancy dealing, I admit) we can have each person's view independent on a per-session basis. That is, the key will be translated into an id _in that person's context_, and the real id's are used to fetch. So a key change will only affect them when their keys refresh. Now we need a strategy for refresh, but hey... one problem at a time. :) Not the best idea I've had, but more to point out that there are some solutions to this that can be fairly simple in practice. Christian Rahul Thakur wrote: [snip] the project.id and projectGroup.id will basically disappear from continuum, reserved strictly for the underlying store. The store can do whatever it wants with them. Ok, so a project(Group)? will have: id : int key : String name : String ... Where key is used as a reference, id is used as a datastore/model identity, and name is used as a display. Sounds good. We could then have a table of old names: id : int oldKey : String These could be used so that failed lookup on a key could then look in the old key's to find out what the new one is (like when you move an issue in JIRA). I'm not sure this is needed initially - only if we support picking up renames to the project itself. [/snip] That was my point in my last email. I understand why we need that old key table but this would be something that will just get bloated over time. There could be a 'housekeeper' process that can clean up old keys after a certain time has expired. I don't see a reason why we need to keep the old stuff for long. Cheers, Rahul -- *christian** gruber + process coach and architect* *Israfil Consulting Services Corporation* *email** [EMAIL PROTECTED] + bus 905.640.1119 + mob 416.998.6023*
Re: short term branch for project/group keys
Sounds great to me. But I'm confused. Are the api's passing around keys as in database keys (id), or so-called business keys, i.e. the project group's text id and the project's text id? I presume the latter, given the earlier discussions. Christian. Jesse McConnell wrote: I am thinking about pulling a short term branch of continuum with rahul and working on getting everything converted to using a string based key project and project group reference in all apis and in all of the UI decision making items. He has tomorrow off so I think that unless anyone has any big issues with it we'll try and make that branch and work on it tomorrow. the end result of it would be: * int id's for project and project group in the model are for internal store usage * name's for project and project group are for presentation purposes only * key's are for all api usage and passing around un URL's etc. some quick benefits are: * consistency across all apis and url manipulations * ability to add quick url rewriting for direct linking of projects foo.org/Doxia/Core * common keys across running continuum instances for clustering jesse -- *christian** gruber + process coach and architect* *Israfil Consulting Services Corporation* *email** [EMAIL PROTECTED] + bus 905.640.1119 + mob 416.998.6023*
Re: short term branch for project/group keys
The web pages use a combination of id's which are currently jpox id's and in some places the actual freeform name string is being passed around on the URL in order to influence program logic and security decisions.. all of that is what I want to unite behind stronger typed string keys. jesse On 12/21/06, Christian Edward Gruber [EMAIL PROTECTED] wrote: Sounds great to me. But I'm confused. Are the api's passing around keys as in database keys (id), or so-called business keys, i.e. the project group's text id and the project's text id? I presume the latter, given the earlier discussions. Christian. Jesse McConnell wrote: I am thinking about pulling a short term branch of continuum with rahul and working on getting everything converted to using a string based key project and project group reference in all apis and in all of the UI decision making items. He has tomorrow off so I think that unless anyone has any big issues with it we'll try and make that branch and work on it tomorrow. the end result of it would be: * int id's for project and project group in the model are for internal store usage * name's for project and project group are for presentation purposes only * key's are for all api usage and passing around un URL's etc. some quick benefits are: * consistency across all apis and url manipulations * ability to add quick url rewriting for direct linking of projects foo.org/Doxia/Core * common keys across running continuum instances for clustering jesse -- *christian** gruber + process coach and architect* *Israfil Consulting Services Corporation* *email** [EMAIL PROTECTED] + bus 905.640.1119 + mob 416.998.6023* -- jesse mcconnell [EMAIL PROTECTED]
Re: short term branch for project/group keys
Sounds good, as long as the store remains independent of them. I don't want to get into the situation like in JIRA where you can't rename a string key. Before starting to hack on this, perhaps you could list out all the keys you think are needed, and some examples? I'm interested in how it relates to group IDs and artifact IDs in particular. - Brett On 22/12/2006, at 6:30 AM, Jesse McConnell wrote: I am thinking about pulling a short term branch of continuum with rahul and working on getting everything converted to using a string based key project and project group reference in all apis and in all of the UI decision making items. He has tomorrow off so I think that unless anyone has any big issues with it we'll try and make that branch and work on it tomorrow. the end result of it would be: * int id's for project and project group in the model are for internal store usage * name's for project and project group are for presentation purposes only * key's are for all api usage and passing around un URL's etc. some quick benefits are: * consistency across all apis and url manipulations * ability to add quick url rewriting for direct linking of projects foo.org/Doxia/Core * common keys across running continuum instances for clustering jesse -- jesse mcconnell [EMAIL PROTECTED]
