One last question though and hopefully I have understood the previous comments…
If the framework has an empty connection dictionary and it is set via the Properties file of the App using it i.e.. dbConnectURLGLOBAL=<some URL> dbConnectUserGLOBAL=<some user> dbConnectPasswordGLOBAL=<some password> What happens if you also include another Model in your app and that uses a different connection dictionary and accesses a different db? How do you get them to know which dictionary is for which? > On 22 Apr 2015, at 20:16, Gino Pacitti <[email protected]> wrote: > > 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 protected]> 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 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/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/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/archive%40mail-archive.com This email sent to [email protected]
