Re: [OpenXPKI-devel] Issues with DBI/SQL abstraction layer

Thu, 22 Mar 2012 05:45:01 -0700 

Hi Micha,

welcome back =)


On 22.03.2012 12:27, Michael Bell wrote:


1. Extend the DYNAMIC hash

We need a key, a value and an operator. The problem with flexibility
is that it is difficult to imagine all the security implications.

Old style:

DYNAMIC->{"NAME"} = "Michael Bell"

New style:

DYNAMIC->{"NAME"}->{"VALUE"} = "Michael Bell"
DYNAMIC->{"NAME"}->{"OPERATOR"} = "EQUAL";
I would go for that one - preferably with a "fallback" to the old form that results in an equal - that way we dont need to touch the old code except where we need another operator than equal. Dynamic currently accepts an array to create OR clauses, I guess that should be kept.
Like is everything we need atm, support for not, less/greater and "less/greater or equal" would be nice. 


We could also use a structure like this:

DYNAMIC->{EQUAL}->{"NAME"} = "Michael Bell"
DYNAMIC->{LIKE}->{"NAME"} = "%Bell%"

Dislike - with the "array to OR" option this will look a bit strange

The second proposal looks perhaps nicer but the functionality is
exactly the same. It is only another flavour.

2. Quick and dirty

same as 1.2 ad I dont see a benefit compared to 1

Oliver

--
Protect your environment -  close windows and adopt a penguin!
PGP-Key: 3B2C 8095 A7DF 8BB5 2CFF  8168 CAB7 B0DD 3985 1721

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
OpenXPKI-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-devel

Reply via email to