Hello,
Since it's not my first patch for Postmodern, and most probably not the last one, I can as well subscribe to the list and send patches properly instead of in a private e-mail.
I just made a small update to DAOs to use constraints (foreign keys, checks, indices) for DAO slots and classes. Doesn't seem to break anything, and makes it possible (or almost possible) to drop separate .sql definition files and just use DAO-TABLE-DEFINITION.
What's missing for me is arbitrary SQL for e.g. defining needed functions, enum types and so on before creating table -- but I'm not sure what approach should I take: move it all to DAOs (as e.g. :BEFORE- CREATE-TABLE and :AFTER-CREATE-TABLE class slots), or just make init function for my package, which would call needed queries and use DAO- TABLE-DEFINITION just to create the tables. Would there be any advantage to :BEFORE-... and :AFTER-... slots, or is the init function the preferred way to go?
Regards, Maciej.
Hey Maciej,
I have no time to look into this right away -- but did you see the deftable stuff? The idea is that you combine all the stuff needed to define a table or view in a deftable form. I intentionally didn't include complicated functionality in the DAO syntax, since they are just access objects, not definitions, and trying to support everything there is an endless labour. Constraints can be added after a table has been defined, which is how I usually do it (if I remember correctly theres already a !foreign operator, and similar ones can be defined for other useful constraints).
Cheers, Marijn
2008/10/11 Maciej Pasternacki maciej@pasternacki.net:
Hello,
Since it's not my first patch for Postmodern, and most probably not the last one, I can as well subscribe to the list and send patches properly instead of in a private e-mail.
I just made a small update to DAOs to use constraints (foreign keys, checks, indices) for DAO slots and classes. Doesn't seem to break anything, and makes it possible (or almost possible) to drop separate .sql definition files and just use DAO-TABLE-DEFINITION.
What's missing for me is arbitrary SQL for e.g. defining needed functions, enum types and so on before creating table -- but I'm not sure what approach should I take: move it all to DAOs (as e.g. :BEFORE-CREATE-TABLE and :AFTER-CREATE-TABLE class slots), or just make init function for my package, which would call needed queries and use DAO-TABLE-DEFINITION just to create the tables. Would there be any advantage to :BEFORE-... and :AFTER-... slots, or is the init function the preferred way to go?
Regards, Maciej.
-- -><- Maciej Pasternacki -><- http://www.pasternacki.net/ -><-
postmodern-devel mailing list postmodern-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
Hello,
DEFTABLE seems fine (or "almost" fine, I'll have to actually try it) for before/after code as I need it, but the constraints inside DAOs seem to be what I actually need.
Here's what I'm trying to achieve: separate single-component library with basic functionality (for e.g. Wordpress-like taxonomy applicable to any "item" in any "site", or for user accounts with registration, activation, password recovery and such); data model entities represented by DAOs; DAO-level inheritance to support project-specific functionality (e.g. user-profile columns, specific foreign keys for taxonomy, and so on). With constraints supported by DAOs it's possible to actually inherit the real schema, and DEFTABLE doesn't support inheritance -- it seems it would be hard to add, and it wouldn't fit well there. Putting constraints in DEFTABLE would break on DAO inheritance, and putting them in DAOs makes it possible not to tinker with hand-written SQL and fitting it to DAOs for every specific use case.
However, the more I think about before/after SQL forms, the more it seems they don't actually belong to DAOs and using DEFTABLE or custom init functions will be a better way. BTW, thanks for pointing out the DEFTABLE -- it named a completely different feature before (or there was a similar name), and I didn't notice it's a new one.
Regards, Maciej
On 2008-10-11, at 12:24, Marijn Haverbeke wrote:
Hey Maciej,
I have no time to look into this right away -- but did you see the deftable stuff? The idea is that you combine all the stuff needed to define a table or view in a deftable form. I intentionally didn't include complicated functionality in the DAO syntax, since they are just access objects, not definitions, and trying to support everything there is an endless labour. Constraints can be added after a table has been defined, which is how I usually do it (if I remember correctly theres already a !foreign operator, and similar ones can be defined for other useful constraints).
Cheers, Marijn
2008/10/11 Maciej Pasternacki maciej@pasternacki.net:
Hello,
Since it's not my first patch for Postmodern, and most probably not the last one, I can as well subscribe to the list and send patches properly instead of in a private e-mail.
I just made a small update to DAOs to use constraints (foreign keys, checks, indices) for DAO slots and classes. Doesn't seem to break anything, and makes it possible (or almost possible) to drop separate .sql definition files and just use DAO-TABLE-DEFINITION.
What's missing for me is arbitrary SQL for e.g. defining needed functions, enum types and so on before creating table -- but I'm not sure what approach should I take: move it all to DAOs (as e.g. :BEFORE-CREATE-TABLE and :AFTER-CREATE-TABLE class slots), or just make init function for my package, which would call needed queries and use DAO-TABLE-DEFINITION just to create the tables. Would there be any advantage to :BEFORE-... and :AFTER-... slots, or is the init function the preferred way to go?
Regards, Maciej.
-- -><- Maciej Pasternacki -><- http://www.pasternacki.net/ -><-
postmodern-devel mailing list postmodern-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
postmodern-devel mailing list postmodern-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
On 2008-10-11, at 13:12, Marijn Haverbeke wrote:
and DEFTABLE doesn't support inheritance
Just to be clear -- deftable just wraps a list of strings or stuff that can be evaluated to strings, so everything that can be expressed in SQL can be expressed in deftable.
I understand how DEFTABLE works (I think so), and it doesn't support what I actually need. I want to use DAO inheritance, which is supported, but currently to use constraints in DAO tables, I need to specify them separately for parent and child class. DEFTABLE doesn't help here, because it allows only to define a specific table, without any extension, application of same constraints to "child" tables, and so on. Maybe initialization function taking class or class name as an argument would help -- however, it seems to me that constraints belong to DAO classes in the same way column types do.
Regards, Maciek
however, it seems to me that constraints belong to DAO classes in the same way column types do.
The way I see it, DAO classes are purely access object declarations. The column types are already borderline irrelevant, but since it's often extremely convenient to only have to list your columns once, I include them there. Constraints can easily be specified outside of CREATE TABLE statements, so there's no pressing reason to include them in DAO definitions.
Best, Marijn
postmodern-devel@common-lisp.net
-
Maciej Pasternacki -
Marijn Haverbeke