| Marker attributes representing complex objects [message #331157] |
Tue, 26 August 2008 22:56  |
Eclipse User |
|
|
|
Originally posted by: rob.brainkandy-dot-org.org
I would like to store objects in markers. These are objects with complicated
heirarchy. They're not terribly big, but big enough that manually serializing
their data and storing them as String objects in the marker means contending
with creating my own pipe-separated protocol.
I'm not in love with this solution. Some other solutions I can think of are:
1. Make the objects serializable, and then store the uuencoded version of that
data as a String.
2. Split the data among several attributes.
3. Some other solution that other people have considered.
What do you think?
|
|
|
| Re: Marker attributes representing complex objects [message #331162 is a reply to message #331157] |
Wed, 27 August 2008 09:23  |
| Eclipse User |
|
|
|
Originally posted by: mario.winterer.gmx.net
Hi Robert!
I don't think, resource markers are the right place to store large
amount of data. The concrete usecase behind this requirement would be
interesting...
Maybe you could just store some kind of identifier in the marker and
have the objects itself in a separate data storage (e.g. a file in the
plugin's storage location). A central service could map the identifier
to the object graph and handle loading and saving of those objects.
Use a resource change listener to synchronize the data storage with the
workspace (i.e. delete objects in the storage if the corresponding
resource has been removed or the corresponding id-marker has been
deleted etc.).
Mario
Robert Konigsberg schrieb:
> I would like to store objects in markers. These are objects with
> complicated heirarchy. They're not terribly big, but big enough that
> manually serializing their data and storing them as String objects in
> the marker means contending with creating my own pipe-separated protocol.
>
> I'm not in love with this solution. Some other solutions I can think of
> are:
>
> 1. Make the objects serializable, and then store the uuencoded version
> of that data as a String.
> 2. Split the data among several attributes.
> 3. Some other solution that other people have considered.
>
> What do you think?
|
|
|
| Re: Marker attributes representing complex objects [message #331199 is a reply to message #331162] |
Thu, 28 August 2008 02:06 |
| Eclipse User |
|
|
|
Originally posted by: rob.brainkandy-dot-org.org
Thanks for the reply, Mario.
The solution we went for was to serialize the object, get the object bytes and
store it as a UTF-8 string.
Does anyone see any real issues with this?
Mario Winterer wrote:
> Hi Robert!
>
> I don't think, resource markers are the right place to store large
> amount of data. The concrete usecase behind this requirement would be
> interesting...
>
> Maybe you could just store some kind of identifier in the marker and
> have the objects itself in a separate data storage (e.g. a file in the
> plugin's storage location). A central service could map the identifier
> to the object graph and handle loading and saving of those objects.
> Use a resource change listener to synchronize the data storage with the
> workspace (i.e. delete objects in the storage if the corresponding
> resource has been removed or the corresponding id-marker has been
> deleted etc.).
That's reall overkill. The data isn't _that_ large, it's just non-trivial.
> Mario
>
> Robert Konigsberg schrieb:
>
>> I would like to store objects in markers. These are objects with
>> complicated heirarchy. They're not terribly big, but big enough that
>> manually serializing their data and storing them as String objects in
>> the marker means contending with creating my own pipe-separated protocol.
>>
>> I'm not in love with this solution. Some other solutions I can think
>> of are:
>>
>> 1. Make the objects serializable, and then store the uuencoded version
>> of that data as a String.
>> 2. Split the data among several attributes.
>> 3. Some other solution that other people have considered.
>>
>> What do you think?
|
|
|
Powered by
FUDForum. Page generated in 0.05373 seconds
] 
Search
Help
Register
Login
Home
