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/archive%40mail-archive.com This email sent to [email protected]
