[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [tigerstripe-dev] RE: Some questions.

Of course the corollary to this is the actual implementation of the validation.

As it is now we have additional restrictions (names and such) because of the POJO-based persistence. It seems as we allow other mechanisms of persistence (although POJO will still be there and the preferred mechanism in some existing installs for obvious reasons) some different restriction might be needed. This means the implementation should allow to delegate the validation to the repository somehow.

 

Eric

 


From: tigerstripe-dev-bounces@xxxxxxxxxxx [mailto:tigerstripe-dev-bounces@xxxxxxxxxxx] On Behalf Of Eric Dillon (erdillon)
Sent: Wednesday, February 20, 2008 6:44 AM
To: Richard Craddock (rcraddoc)
Cc: Tigerstripe developers list
Subject: 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?

Eric

 

 


From: Richard Craddock (rcraddoc)
Sent: Wednesday, February 20, 2008 6:21 AM
To: Eric Dillon (erdillon)
Subject: RE: [tigerstripe-dev] RE: Some questions.

 

217970

 

 

I agree with doing it in the context of EMF, but to write a test case, I need to have a "design" :-)

 

 

 


From: Eric Dillon (erdillon)
Sent: 20 February 2008 14:14
To: Richard Craddock (rcraddoc); 'Tigerstripe developers list'
Subject: RE: [tigerstripe-dev] RE: Some questions.

Cool. More comments below.

 

Eric

 


From: Richard Craddock (rcraddoc)
Sent: Wednesday, February 20, 2008 4:02 AM
To: Tigerstripe developers list; Eric Dillon (erdillon)
Subject: RE: [tigerstripe-dev] RE: Some questions.

 

Eric,

 

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.

 

RC

 

 


From: tigerstripe-dev-bounces@xxxxxxxxxxx [mailto:tigerstripe-dev-bounces@xxxxxxxxxxx] On Behalf Of Richard Craddock (rcraddoc)
Sent: 20 February 2008 09:05
To: Eric Dillon (erdillon)
Cc: Tigerstripe developers list
Subject: [tigerstripe-dev] RE: Some questions.

Hi Eric,

 

 good work!

 

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?

 

RC

 


From: Eric Dillon (erdillon)
Sent: 20 February 2008 00:38
To: Richard Craddock (rcraddoc)
Cc: Jim Strawn (jistrawn); Duncan Keysell (dkeysell); 'Tigerstripe developers list'
Subject: RE: Some questions.

Hi Richard,

 

See my comments inline.

 

Eric

 


From: Richard Craddock (rcraddoc)
Sent: Tuesday, February 19, 2008 8:34 AM
To: Eric Dillon (erdillon)
Cc: Jim Strawn (jistrawn); Duncan Keysell (dkeysell)
Subject: Some questions.

 

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.

 

 

 

Still going....

 

 

RC