On Jan 4, 2010, at 5:06 PM, Tim Worman wrote:
> On Jan 4, 2010, at 4:39 PM, Chuck Hill wrote:
>
>> On Jan 4, 2010, at 4:30 PM, Tim Worman wrote:
>>> On Jan 4, 2010, at 4:00 PM, David Avendasora wrote:
>>>> On Jan 4, 2010, at 6:42 PM, Tim Worman wrote:
>>>>> On Jan 4, 2010, at 3:27 PM, Chuck Hill wrote:
>>>>>> On Jan 4, 2010, at 3:13 PM, Tim Worman wrote:
>>>>>>
>>>>>>> Is it pretty much a certainty that the error I'm experiencing is caused
>>>>>>> by a problem in my models? This problem is a show stopper for me right
>>>>>>> now. Just for refresher, the error is:
>>>>>>>
>>>>>>> Error: java.lang.IllegalStateException: The object with globalID
>>>>>>> _EOIntegralKeyGlobalID[Timesheet (java.lang.Long)10253] could not be
>>>>>>> found in the database. This could be result of a referential integrity
>>>>>>> problem with the database. An empty fault could not be created because
>>>>>>> the object's class could not be determined (e.g. the GID is temporary
>>>>>>> or it is for an abstract entity)
>>>>>>
>>>>>> Does a Timesheet with a 10253 actually exist in the database? Is
>>>>>> Timesheet in an inheritance hierarchy? If so, check very, very
>>>>>> carefully for a duplicated PK.
>>>>>
>>>>> Timesheet is in an inheritance hierarchy. From the original post, this is
>>>>> how Timesheet is modeled:
>>>>>
>>>>> Timesheet (abstract parent) <-----------------< TimeEntry (just a time
>>>>> entry on a timesheet)
>>>>> TimesheetExempt (child)
>>>>> TimesheetNonExempt(child)
>>>>>
>>>>> Yes, there is a Timesheet with timesheet_id=10253. There are no Timesheet
>>>>> with duplicate timesheet_id. The error is thrown when
>>>>> TimeEntry.timesheet() is called.
>>>>
>>>> What is the restricting qualifier on each Timesheet entity?
>>>>
>>>> Dave
>>>
>>> Timesheet is abstract and does not have a restricting qualifier.
>>
>> And that, IIRC, is your problem. Add one that matches nothing.
>
> Ya know - I'm feeling some deja vu about this. I probably am just ridiculous
> enough to reach a similar problem twice and have a conversation with you
> about it. Sorry if that's the case. Anyway, is this what you're suggesting?
>
> TimesheetAbstract (no restricting qual)
> TimesheetGeneric (1=0 or some such - I think I may have tried that qual
> before and it didn't work)
> TimesheetExempt (isExempt=1)
> TimesheetNonExempt (isExempt=0)
My bad:
Timesheet (abstract with qualifier like exemptStatus="Z")
TimesheetExempt (qualifier like exemptStatus="E")
TimesheetExempt (qualifier like exemptStatus="N")
I guess I just don't understand the logic behind giving the abstract parent
entity a restricting qualifier. It seems really counterintuitive to me. But if
it is necessary, it's necessary.
T
>
>
>>> The entity has an attribute 'isExempt' which is boolean and modeled using
>>> the toString approach. So, 'true' and 'false' are being stored in the
>>> database. My restricting qualifiers for the child entities is as follows:
>>>
>>> TimesheetExempt: 'isExempt=1'
>>> TimesheetNonExempt: 'isExempt=0'
>>>
>>> Maybe I would be better off not using a boolean attribute and instead have
>>> a string flag of with values of 'E' and 'N?' Then I could put a cover
>>> method Timesheet.isExempt() to return the boolean.
>>
>> Can Timesheets ever change from Exempt to Non-Exempt? Where is Kieran to
>> tell you to use the Role pattern for this? Kieran? Hello?
>
> No, they can't. A Timesheet is either exempt or non-exempt because it belongs
> to a Job that is either exempt or non-exempt. That status can't change for a
> job or a timesheet so I'm guaranteed safe to model it if I can get it working.
>
>> I think the best practices for restricting values are:
>> 1. Don't try to be clever. Use E and N.
>
> OK, I'm going to try and re-model it like that and see if it makes a
> difference.
>
>> 2. Don't use the restricting value for anything else. Ever.
>
>> public boolean isExempt() { return
>> TimesheetExempt.ENTITY_NAME.equals(entityName()));
>> or add another column, or something.
>
> OK, thanks for that - I would not have done that for sure. :-)
>
> Tim
>
>> Chuck
>>>
>>> Tim
>>>
>>>>>
>>>>> Tim
>>>>>
>>>>>> Chuck
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> I've tested the equality of the connection dictionaries of the models
>>>>>>> and they are equal.
>>>>>>>
>>>>>>> Tim Worman
>>>>>>> UCLA GSE&IS
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Dec 31, 2009, at 12:36 AM, Tim Worman wrote:
>>>>>>>
>>>>>>>> On Dec 30, 2009, at 3:18 AM, David Avendasora wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Dec 29, 2009, at 9:46 PM, Tim Worman wrote:
>>>>>>>>>
>>>>>>>>>> OK, so, I've reviewed all the prototypes in use, data types, etc. I
>>>>>>>>>> did find some areas where my prototypes were messed up so it was
>>>>>>>>>> worth it to go through it all. The fk and pk both are long values.
>>>>>>>>>>
>>>>>>>>>> But I'm still getting the same error. This solution also doesn't
>>>>>>>>>> cross databases. It does crosses models at this point. But the
>>>>>>>>>> TimeEntry and Timesheet entities are in the same model.
>>>>>>>>>
>>>>>>>>> If TimeEntry and Timesheet are in the same model, what crosses
>>>>>>>>> models? The inheritance hierarchy? What type of Inheritance are you
>>>>>>>>> using?
>>>>>>>>>
>>>>>>>>> If you have two models that point to the same database you have to be
>>>>>>>>> very careful to make sure that the connection dictionaries of the two
>>>>>>>>> models are EXACTLY IDENTICAL (yelling intended). This is very, very
>>>>>>>>> important. Otherwise they will likely have different
>>>>>>>>> EODatabaseContexts which can cause all manor of EOF confusion when it
>>>>>>>>> comes to assigning keys.
>>>>>>>>>
>>>>>>>>> Read this thread from way back in 2006 where Mike Schrag seemed to
>>>>>>>>> have a similar problem (start at the beginning):
>>>>>>>>> http://lists.apple.com/archives/webobjects-dev//2006/May/msg00530.html
>>>>>>>>
>>>>>>>> Thanks Dave. But I still don't have a solution. I tested all the
>>>>>>>> models that refer to the same database. I'm testing the equality of
>>>>>>>> the connection dictionaries at app launch and they all pass the
>>>>>>>> connectionDictionary().equals() test. There is another JNDI model that
>>>>>>>> obviously refers to an LDAP data source and necessarily the connection
>>>>>>>> dictionary to that is different.
>>>>>>>>
>>>>>>>> Any other ideas about what is causing the problem or troubleshooting
>>>>>>>> techniques you'd employ here? Obviously I'm doing something wrong?
>>>>>>>>
>>>>>>>> Tim
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Dave
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Tim Worman
>>>>>>>>>> UCLA GSE&IS
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Dec 28, 2009, at 4:45 PM, [email protected] wrote:
>>>>>>>>>>
>>>>>>>>>>> Check cross database issues and also name sure the types on your pk
>>>>>>>>>>> and fk match ... I notice that says your fk is a long, make sure
>>>>>>>>>>> that matches the pk of the destination entity.
>>>>>>>>>>>
>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>
>>>>>>>>>>> On Dec 28, 2009, at 7:33 PM, "Tim Worman"<[email protected]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> ...or wondering if I've modeled something incorrectly.
>>>>>>>>>>>>
>>>>>>>>>>>> I've got a model with these Entities:
>>>>>>>>>>>>
>>>>>>>>>>>> Timesheet (abstract parent) >----------------- TimeEntry (just a
>>>>>>>>>>>> time entry on a timesheet)
>>>>>>>>>>>> TimesheetExempt (child)
>>>>>>>>>>>> TimesheetNonExempt(child)
>>>>>>>>>>>>
>>>>>>>>>>>> Everything works fine until a given TimeEntry tries to refer back
>>>>>>>>>>>> to its timesheet by calling timesheet(). At that point I get this
>>>>>>>>>>>> error:
>>>>>>>>>>>>
>>>>>>>>>>>> Error: java.lang.IllegalStateException: The object with
>>>>>>>>>>>> globalID _EOIntegralKeyGlobalID[Timesheet (java.lang.Long)10253]
>>>>>>>>>>>> could not be found in the database. This could be result of a
>>>>>>>>>>>> referential integrity problem with the database. An empty fault
>>>>>>>>>>>> could not be created because the object's class could not be
>>>>>>>>>>>> determined (e.g. the GID is temporary or it is for an abstract
>>>>>>>>>>>> entity)
>>>>>>>>>>>>
>>>>>>>>>>>> It is true that the GID would be for an abstract entity -
>>>>>>>>>>>> Timesheet. But I assumed that a TimeEntry would not need to know
>>>>>>>>>>>> specifically what variety of Timesheet it is dealing with. I guess
>>>>>>>>>>>> the question I have is, what is the better way to model this? Will
>>>>>>>>>>>> it be necessary for me to model TimeEntryExempt and
>>>>>>>>>>>> TimeEntryNonExempt just so the time entries know which type of
>>>>>>>>>>>> timesheet they belong to and don't call the abstract parent?
>>>>>>>>>>>>
>>>>>>>>>>>> Tim
>>>>>>>>>>>> UCLA GSE&IS
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>>>>>>> Webobjects-dev mailing list ([email protected])
>>>>>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com
>>>>>>>>>>>>
>>>>>>>>>>>> This email sent to [email protected]
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>>>>> Webobjects-dev mailing list ([email protected])
>>>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com
>>>>>>>>>>
>>>>>>>>>> This email sent to [email protected]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> David Avendasora
>>>>>>>>> Senior Software Engineer
>>>>>>>>> K12, Inc.
>>>>>>>>>
>>>>>>>>> *****
>>>>>>>>> WebObjects Documentation Wiki :
>>>>>>>>> http://wiki.objectstyle.org/confluence/display/WO/
>>>>>>>>> *****
>>>>>>>>> WebObjects API:
>>>>>>>>> http://developer.apple.com/legacy/mac/library/documentation/MacOSXServer/Reference/WO54_Reference/index.html
>>>>>>>>> *****
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>>> Webobjects-dev mailing list ([email protected])
>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/lists%40thetimmy.com
>>>>>>>>
>>>>>>>> This email sent to [email protected]
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>> Webobjects-dev mailing list ([email protected])
>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net
>>>>>>>
>>>>>>> This email sent to [email protected]
>>>>>>
>>>>>> --
>>>>>> Chuck Hill Senior Consultant / VP Development
>>>>>>
>>>>>> Practical WebObjects - for developers who want to increase their overall
>>>>>> knowledge of WebObjects or who are trying to solve specific problems.
>>>>>> http://www.global-village.net/products/practical_webobjects
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Webobjects-dev mailing list ([email protected])
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com
>>>>>
>>>>> This email sent to [email protected]
>>>>>
>>>>>
>>>>
>>>> David Avendasora
>>>> Senior Software Engineer
>>>> K12, Inc.
>>>>
>>>> *****
>>>> WebObjects Documentation Wiki :
>>>> http://wiki.objectstyle.org/confluence/display/WO/
>>>> *****
>>>> WebObjects API:
>>>> http://developer.apple.com/legacy/mac/library/documentation/MacOSXServer/Reference/WO54_Reference/index.html
>>>> *****
>>>>
>>>
>>
>> --
>> Chuck Hill Senior Consultant / VP Development
>>
>> Practical WebObjects - for developers who want to increase their overall
>> knowledge of WebObjects or who are trying to solve specific problems.
>> http://www.global-village.net/products/practical_webobjects
>>
>>
>>
>>
>>
>>
>>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list ([email protected])
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/lists%40thetimmy.com
>
> This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
