RE: [smila-dev] Partition in Storages: API/Changes Discussion

[Sebastian Voigt <svoigt@xxxxxxx>]

Thanks Dmitry.

Regarding Ivans suggestion:
I think it is not a good idea to add such method (in other cases your suggestion will be ok, because it simplifies the API):
Pipelet developers should not be annoyed with a getPartition method, in most cases they should not care about partitions,
And they should not call a extra methods every time, thus will make development much more difficult for them.
The use case is to store Records in a specific partitions (if intended),
That means the DFP(Rules/Listener) should handle the decision where it is stored,
only in special cases would a pipelet access (read) a specific partition. but in most cases the developer should not be aware of partitions (imho).

> -----Original Message-----
> From: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] On Behalf Of dhazin@xxxxxxxxxxxx
> Sent: Tuesday, November 18, 2008 5:37 PM
> To: Smila project developer mailing list
> Subject: RE: [smila-dev] Partition in Storages: API/Changes Discussion
> 
> Hi Juergen,
> 
> I've extended use case description at the specification page, hope it will
> be more clear for you now. If not, please ask :)
> 
> Thanks,
> Dmitry
> 
> 
> > Hi,
> >
> > Sebastian wrote:
> >
> >> Dmitry has wrote something about Changes to the Blackboard regarding
> >> the Idea to use Partitions in both storages
> >> (for Reuse/Backup & recrawling)
> >>
> >> Feel free to discuss
> >>
> >> http://wiki.eclipse.org/SMILA/Specifications/Partitioning_Storages
> >
> > Sorry, if I missed something, but ...
> > is there a description of the use case anywhere which is a bit longer than
> > a single sentence? I find it a bit hard to discuss specifications for
> > requirements I do not know about (-;
> >
> > Or if there is a more detailed description of the use case somewhere, just
> > put a link in the wiki page, please.
> >
> > Cheers,
> > Juergen.
> > _______________________________________________
> > smila-dev mailing list
> > smila-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/smila-dev
> >
> 
> 
> _______________________________________________
> smila-dev mailing list
> smila-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/smila-dev