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 protected]> 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 protected]> 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 protected]> 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 protected]> 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 protected]> 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 protected]> 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 protected]> 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 protected]> 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 protected]> 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 protected]> 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 protected]) >>>>>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/webobjects%40anazys.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: >>>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/webobjects%40anazys.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: >>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/ginokris%40me.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: >>>>>> https://lists.apple.com/mailman/options/webobjects-dev/webobjects%40anazys.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: >>>> https://lists.apple.com/mailman/options/webobjects-dev/webobjects%40anazys.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: >> https://lists.apple.com/mailman/options/webobjects-dev/webobjects%40anazys.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: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
