Re: data source for “static” objects?
Re: data source for “static” objects?
- Subject: Re: data source for “static” objects?
- From: ocs--- via Webobjects-dev <email@hidden>
- Date: Sun, 7 Jun 2020 20:39:02 +0200
Chuck,
thanks a lot, sounds hopeful :)
Will check. Should you happen to have a link to some sample code at hand, I'd
be grateful; otherwise of course I'll search for it myself :)
Thanks again,
OC
> On 7. 6. 2020, at 8:06 PM, Chuck Hill <email@hidden> wrote:
>
> I think what you want is to subclass EOAadptor, EOAdaptorChannel, and
> EOAdaptorContext and have them talk to your Java classes. The layer above
> (EODatabase etc) can stay are they are.
>
> There have been flat file adataptors, screen scrapers etc. I don’t see why
> what you want could not work. The model the entities are in control the
> EOAdaptor used.
>
> Chuck
>
>
>> On Jun 7, 2020, at 10:02 AM, Aaron Rosenzweig via Webobjects-dev
>> <email@hidden <mailto:email@hidden>>
>> wrote:
>>
>> Hi OC,
>>
>> I suppose you could move your java POJOs into a .jar and then expose them
>> with a java app running on a particular port that masquerades as a DB
>> endpoint. I’m not sure it’s worth the trouble but it could be done. This
>> would be the “my DB in a box” solution where you essentially make trimmed
>> down DB server that doesn’t allow updates but allows SQL queries. It gets
>> weird though with EOF and honestly I’ve never tried jumping DBs for foreign
>> keys. I’ve only used multiple DBs to do queries on unrelated data.
>>
>> I assume you like how handy it is to have the java classes at your finger
>> tips and able to edit them when needed but you also like to be able to query
>> in SQL for various attributes that those POJOs have… so you go to the
>> trouble of making an EO doppelgänger that you have to sync.
>>
>> Perhaps you can make your POJOs enums? If that’s feasible then you could use
>> the enum prototype in your EO so that instead of having an FK it is an
>> attribute of an enum type.
>>
>> If enums are not feasible then maybe you should stop thinking of them as
>> POJOs and make them EOs which you have to change via SQL migrations instead
>> of twiddling java classes. That would be the path of least resistance. Since
>> they are pretty much read only, you could consider making them shared Eos
>> but it’s not mandatory to do so.
>> AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/>
>> e: email@hidden <mailto:email@hidden> t: (301) 956-2319
>>
>>
>>> On Jun 7, 2020, at 12:37 PM, ocs--- via Webobjects-dev
>>> <email@hidden <mailto:email@hidden>>
>>> wrote:
>>>
>>> Hi there,
>>>
>>> let me please ask another weird question. For the context, thing is, one of
>>> our applications supports “predefined” EOs -- things like static lists and
>>> similar. In our case, they are completely defined in the Java code -- the
>>> number of them, all their attributes, whatever. Then, runtime, they are
>>> shared for all users/sessions/editing contexts.
>>>
>>> Since they need to be real EOs (they mix with normal dynamically defined
>>> objects, they are part of relationships, etc), it brings non-trivial
>>> problem how to implement the stuff.
>>>
>>> At this moment, we
>>> - at launch, synchronise these objects into the database: if the Java code
>>> defines a new object which has not been there, it is inserted; if there are
>>> changes in attributes, they are updated. If an object of this kind is found
>>> in the database and there's no description for it in the Java code, it is
>>> deleted;
>>> - then we load them into the shared EC for all users to share them.
>>>
>>> It works, but the synchronisation approach is ugly; it feels sort of wrong
>>> to keep copies of those static objects in the database.
>>>
>>> Now, I wonder: EOF does support multiple data sources. How difficult and
>>> error-prone would it be to implement my own data source, which would --
>>> instead of from a DB -- “load” objects from the application predefined
>>> code? Would it be possible? Wouldn't it bring more problems than the old
>>> code did? To illustrate the idea, here's the notorious Apple pic, tweaked
>>> appropriately:
>>>
>>> <canThisBeDone.jpg>
>>> Has anybody out there already tried something like that, and if so, with
>>> any luck?
>>>
>>> Thanks,
>>> OC
>>>
>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden
>>> <mailto:email@hidden>)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>>
>>> This email sent to email@hidden <mailto:email@hidden>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden
>> <mailto:email@hidden>)
>> Help/Unsubscribe/Update your Subscription:
>>
>>
>> This email sent to email@hidden <mailto: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