|RE: [tigerstripe-dev] RE: Some questions.|
What do you a mean a “design” J?
Well I guess 2 things come to mind:
In the EMF world you won’t be doing doSave() any more. There would be 2 occurrences when a validation is required:
- Upon initial “store(…)” into a IModelRepository. This could throw an Exception due to the fact that the object you’re trying to store is invalid.
- Upon commit of a TX when trying to change attributes on an object that is already living in a store. I guess we should rollback the transaction and post the failure through the official mechanism (not sure what the details are yet with EMF Transaction for that).
That being said it would rely on an internal method to “validate/visit” the object (Visitor pattern) and potentially gather problems/warnings, etc. It would probably be a good idea to make this method part of the API so you don’t have to “wait” all the way until you try to commit.
Also, I suspect the auditor would rely on that too.
Does that make any sense?
I agree with doing it in the context of EMF, but to write a test case, I need to have a "design" :-)
Cool. More comments below.
all your fixes are good.
Item 3 . Change made.
Item 6. My bad. IRelationshipEnd already has a getOtherEnd(). no change needed.
Re: bug 217290 - Should this simply throw a TigerstripeException if the type being attempted to set is invalid?
This makes me think of a few other things - like if I create anything through the API, bit don't set a Type - what should the app do? Allow you to save it anyway? (I think that is what happens now). Maybe we should have some "minimal requirements" to make an attribute/field/method etc valid ?
[ER>] what’s the correct bug number… this is not a Tigerstripe bug. I tried some combination but couldn’t guess J.
I believe we have some validation logic being triggered through the UI, not sure how it’s hook in the API. If it is not, it would need to be! I’d prefer to look into this within the context of the EMF move though unless it is a quick fix.
Behalf Of Richard Craddock (rcraddoc)
I'll be carrying on today, but have a process question - if you (or anyone else) have fixed a bug and I'm happy with it should I close it, or de we wait until we have a formal build with it in?
See my comments inline.
I raised bugs where I could. Heres a variety of thoughts/questions
[ER>] I’ve addressed 219420, 219444, 219450, 219454, 217823, 217825. This will be in tonight’s nightly build.
1. What is the option "Cascade Delete References" for in the Preferences/General tab for ? I've never noticed it before......
[ER>] I initially couldn’t remember what this could be, but I remember talking with Chris about this case: when deleting an artifact from the model that has incoming or outgoing associations, these associations/relations are currently left “dangling”. This option mean that all relationships would be removed as well. I am unclear as what is really implemented, so I would be in favor of removing this option from the GUI until we can vouch for what it really means L.
2. I think we need to review the OSS/J settings in the "factory default" profile - the OSS/J specifics appear unless you turn them off - should be the reverse ?
[ER>] Agreed. The OSSJ settings should all be turned off by default.
3. On Method we have a method called getMethodReturnName() - is might be simpler to just have getReturnName()
[ER>] Please make the change.
4. I seem to remember that *somewhere* in the code you can query an AbstractArtifact to see if it supports Methods, Constants etc. This might be quite handy to add to the API. And add a similar thing to say if it has Ends.
[ER>] As discussed briefly on the phone today, I think it makes sense to provide a way to “introspect” the artifacts. This will be needed/available from the EMF implementation later on. I was hoping to get around to doing it today… not sure anymore. I’ll send you an email if I do finish this tonight.
5. Isn't the refBy stuff really an OSS/J specific ?
[ER>] Hmmm…. This needs to be thought thru. It should indeed be considered as an OSSJ extension in the metamodel, but it is currently embedded quite deeply in the core, so we have look at the consequences…
6. On an associationEnd - there is no current method to say if it is the AEnd or ZEnd of a relationship - I'm not sure exactly what this truly means in context as the navigability are the truly useful things, but we have had to do some (admittedly simple) checking whenever we want to get the "otherEnd". Maybe a couple of methods could be added isAEnd() isZEnd() ?
[ER>] I believe there is a getOtherEnd() method on the implementation of IAssociationEnd. It should simply be a matter of pushing this into the IAssociationEnd Interface and it should do the trick?
7. (Warning - Modelling question!) Still on the associationEnd - we have Multiplicity, but we also have a type which has multiplicity - the TypeMultiplicity is always 0..1 - should that be 1, or is it really irrelevant?
[ER>] Yes. This is a bit redundant. IAssociationEnd exposes a multiplicity, and the IType on that end does too. For consistency we should probably use the IType one only. Also, we need to look into migrating the current Enumeration-based multiplicity to support arbitrary bounds (upperBound, lowerBound).
8. (This is very minor) when I add an attribute to an artifact it generates the names attriubute0, attribute1, attriubute2 . If I then switch artifact, it starts at attriubute2 ....
[ER>] Yes, a little annoyance indeed, maybe there is a “static” somewhere we should remove J.