Re: Framework EOModels
Re: Framework EOModels
- Subject: Re: Framework EOModels
- From: Gino Pacitti <email@hidden>
- Date: Wed, 22 Apr 2015 20:16:17 +0100
And thanks Chuck… Its a client with multiple apps and I was just trying to normalise things…
Now I have a much better point of view for planning future actions…
:-)
> On 22 Apr 2015, at 20:10, Gino Pacitti <email@hidden> wrote:
>
> Super… I was not looking at it from that point of view… thanks for the clarification!!!!!
>
>
>> On 22 Apr 2015, at 20:04, Dev WO <email@hidden> wrote:
>>
>> not only more generic, if you create a framework it is for code-reuse purpose. The actual execution of the software is done by the app, so the app is the part that need to have the relevant settings for it to run.
>> Let’s illustrate that for a second:
>> -you create a framework for managing customer and payment transaction
>> -you develop a store app that you provide to multiple clients
>> => Do you really want that all your clients have access to all customers and payment transactions?:)
>> So what you do is that you change some settings at the app level (through different Properties file for each client or through client-specific launch argument for example) and deploy an app for each client, so each of them is isolated.
>>
>> Xavier
>>
>>> On 22 avr. 2015, at 20:54, Gino Pacitti <email@hidden> wrote:
>>>
>>> Ah… duh!!!!!!!
>>> So leaving the connection dictionary and setting it in your app is much more generic… :-)
>>>
>>> That is what you mean - right?
>>>
>>>
>>>
>>>
>>>> On 22 Apr 2015, at 19:23, Dev WO <email@hidden> wrote:
>>>>
>>>> You’re missing something:)
>>>> Your framework doesn’t need to be tied to a specific db (not even a specific db vendor).
>>>> You usually left the settings/connection to the app itself through some Wonder properties:
>>>> #dbConnectURLGLOBAL=
>>>> #dbConnectUserGLOBAL=
>>>> #dbConnectPasswordGLOBAL=
>>>> etc
>>>> When you create a “Wonder App” through Eclipse, you should get a bunch of properties available to you in Resources/Properties, check it out.
>>>>
>>>> Xavier
>>>>
>>>>
>>>>> On 22 avr. 2015, at 20:19, Gino Pacitti <email@hidden> wrote:
>>>>>
>>>>> Ok, thanks for the clarification…
>>>>>
>>>>> Well if the Framework uses a single DB in the connection dictionary then it seems to me that the pattern dictates that writing a record would be to a single db and to a particular table.
>>>>>
>>>>> Or am I missing something really fundamental?
>>>>>
>>>>> I’m just trying to normalise my code into a Framework and write a record independent of the App.
>>>>>
>>>>>
>>>>>
>>>>>> On 22 Apr 2015, at 19:06, Dev WO <email@hidden> wrote:
>>>>>>
>>>>>> EOF will take care of your primary keys/insertion without conflict.
>>>>>>
>>>>>> Despite the fact that you won’t have conflict, I don’t really understand why you would need 2 apps to write to the same db the same kind of object. I just don’t get it, but maybe it’s clear for you:)
>>>>>>
>>>>>> Xavier
>>>>>>
>>>>>>> On 22 avr. 2015, at 19:56, Gino Pacitti <email@hidden> wrote:
>>>>>>>
>>>>>>> Well if the Framework EOModel is tied to a single DB and set of tables then all the Apps would be using the same data source. Obviously the Apps would have different stacks and freshness would be an issue… but I was more concerned with two records for the same DB and table being created and saved.
>>>>>>>
>>>>>>> For example a payment system where more than 1 app might use the Framework.
>>>>>>> App1 needs to store a transaction ID in a TransactionObject and App2 needs to store a transactionID in a Transaction Object. These objects which have TempGlobalIDs have not been saved as yet but the moment one is saved the EO_PK_Table is updated with a PK for the TransactionObject. But then if the other TransactionObject is attempted to be saved what would happen… would there be a conflict or as you say are they completely independent and the EOF would handle it and save the other TransactionObject with a non conflicting PK?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 22 Apr 2015, at 18:40, Dev WO <email@hidden> wrote:
>>>>>>>>
>>>>>>>> Assuming you have a specific db for each app of course. If not, the objects are still all independent, but you’ll have to deal with data freshness/communication between the 2 apps as they would access the same storage.
>>>>>>>>
>>>>>>>> Xavier
>>>>>>>>
>>>>>>>>> On 22 avr. 2015, at 19:42, Gino Pacitti <email@hidden> wrote:
>>>>>>>>>
>>>>>>>>> Ah Ok.. so even if 10 apps use the same Framework every EOObject is completely safe and no conflicts for PKs…
>>>>>>>>>
>>>>>>>>> Great...
>>>>>>>>>
>>>>>>>>>> On 22 Apr 2015, at 18:36, Dev WO <email@hidden> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Gino,
>>>>>>>>>>
>>>>>>>>>> Everything is completely independent.
>>>>>>>>>> No conflict.
>>>>>>>>>> That’s actually why you create frameworks;)
>>>>>>>>>>
>>>>>>>>>> Xavier
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On 22 avr. 2015, at 19:17, Gino Pacitti <email@hidden> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I was planning a Framework which has an EOModel that two different apps will use. Is there a potential of conflicts when each app tries to create a record and save to db?
>>>>>>>>>>>
>>>>>>>>>>> Specifically if app1 creates an EOEnterprise Object and modifies it and does not save and at the same time app2 creates an EOEnterprise Object and does save… Does the Framework follow the creation of TempGlobalIDs and does not allow conflicts to occur when that Framework is being used between apps?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>>>>>> Webobjects-dev mailing list (email@hidden)
>>>>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>>>>>
>>>>>>>>>>> This email sent to email@hidden
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>>>> Webobjects-dev mailing list (email@hidden)
>>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>>>
>>>>>>>>> This email sent to email@hidden
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>>> Webobjects-dev mailing list (email@hidden)
>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>>
>>>>>>>> This email sent to email@hidden
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>> Webobjects-dev mailing list (email@hidden)
>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>
>>>>>>> This email sent to email@hidden
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Webobjects-dev mailing list (email@hidden)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>
>>>>> This email sent to email@hidden
>>>>
>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden